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Revision 3.0, November 24,2003 

Incorporate A64 addressing from VME64. Adds 2eVME protocol from VI\/IE64x, Chapter 11. The following 
sections are significantly affected. Removes Section G. 

Section B 
Section C 

Section G is removed from the specification; appropriate references to pertinent VXI specs regarding Shared 
Memory are added where required. 

Revision 4.0, September 2009 

Updated specification to include ANSIA/ITA 1.1-1994 (VME64), ANSI/VITA 1.1-1997 (VME64x), ANSI/VITA 
1.5-2003 (2eSST), ANSIA/ITA 41 .Ox-2006 (VXS Core), and VITA 41.6 (Control Plane on VXS) standards. 

Key features and changes added to this standard encompass these major areas: 

1) "z" and "d" pin rows to the P1/J1 and P2/J2 connectors for 160 pins in each connector. 

2) PO/JO connector to support VME Switched Serial (VXS) modules on up to 13 VXS/VXI slots and 1 or 2 
non-VXI slots for supporting VXS Switch Modules with J2-J5 backplane connectors. 

3) 43 ground return pins (38 plus 5 MFBL). This will improve the signal quality on the bus, for new 
protocols such as 2eSST. 

4) 10 pins for -I-3.3V. As more and more electronic components are using lower supply voltages 

then the formerly default 5V, the availability of 3.3V on the bus will help saving real estate on the modules 
as well as reduce the power consumption. 

5) 5 pins for -r5V (2 plus 3 VPC). 

6) 1 pin for -r12V, -12V, -r24V and -24V each. 

7) 8 auxiliary power pins (±V1-V4) for supplying additional voltages to the modules from supplies external 
to the mainframe but supplied to the backplane connectors. 

8) Addition of 8 Local Bus lines for a total of 20 

9) Addition of CLK100 and SYNC100 signals 

10) Added pins SDAO/SCLO and SDA1/SCL1 to implement two I2C busses to allow control/monitoring of 
backplane and mainframe resources 

11) Added Star Trigger lines iSTRIGxIN and iSTRIGxOUT for precise simultaneous system wide 
triggering and sampling 

12) Added section on 2eSST (two edge source-synchronous transfer) protocol which permits theoretical 
block transfers up to 320Mbytes/s. 

Revision 4.0, Rev 2, May 3, 2010 

Made the following changes based upon review: 

1) Changed VXIbus logo on front page, revision date, and move to Revision 2 of 4.0 specification 

2) Changed above -11) Added Star Trigger lines ±STRGIN0-2 and ±STRGOUT01-12 for precise 
simultaneous system wide triggering and sampling 

3) Changes to B.6.2 related to P2 “z” and “d” section. Moving from 8 auxiliary power pins to including 
details on 8 defined local lines, 4 pairs of Star Triggers, and reducing to 4 auxiliary power pins, 
augmenting the VME64x-defined -I-V1/-V1, -I-V2/-V2 on PI connector 

4) Changes to Table B.1.1 for P2 definitions: Slots 1-12 related to Star Trigger Bus 

5) Changes to Table B.2 related to Star Trigger Bus 

6) Changes to B.6.2.9 Star Trigger Lines opening section to support prior changes to Star Trigger Bus tables 

7) Figure B.13.1 changed to support new Star Trigger Bus configuration 

8) Rule 6.77.1 modified for changes in pin labeling and signal performance 

9) Observation B.6.16.2 changed to clarify description related to track length and propagation delays 

10) Figure B.13.2 replaced to better illustrate communication between Slot 0 and modules for Star Trigger 
Bus 

11) B.6.77.3, B.6.77.4, and B.6.77.5 modified with supporting pin-out requirements and performance. 

12) B.6.6 typo correction of 3.125Bbps to 3.125Gbps. 

13) Section B.6.4 clarification on differences between JO and PO pinouts. 

14) Changed Figure B.54 to illustrated recommended VXI-VXS backplane. 

15) Keying rules for VXS modules in Section B.13 converted to PERMISSION. 



Revision 4.0, Rev 2, May 16, 2010 


1) Deprecated D-size module information where it was specifically D-size. Combinations of C and 
D-size figures, text, rules. Etc. were left untouched. 

2) Deprecated Appendix II sections 

3) General clean-up of text, figure labeling, removing table coloring, and removal of text calling for 
focus by reviewers. 

4) Clarification of PO information related to different row count between Module and Backplane 

Revision 4.0, May 27, 2010 

1) Title page: Editorial changes removing “Draft” and warning. Changed date to May 27. 

2) Page 3: Corrected list of sponsor members. 

3) Footer: Updated to Rev. 4.0 and May 27. 
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VMEbus Extensions for Instrumentation 

System Specification 


A. INTRODUCTION to VXIbus SPECIFICATIONS 


This document discusses the VXIbus Family of VMEbus compatible modular instrumentation. It is intended 
to be used by designers interested in generating compatible components for the system. 

The architectural concepts of the VMEbus date back to Motorola's development of the 68000 microprocessor 
in the late 1970's. In late 1979, Motorola published a brief description of a 68000 oriented bus known as 
VERS Abus. Several revisions followed, the last being in July 1981. 

At the same time, a new printed circuit board standard (lEC 297-3) was being developed, known as the 
"Eurocard" standard. In October 1981, Motorola, Mostek and Signetics announced their agreement to support 
a line of cards based on the VERSAbus with Eurocard module dimensions, which was renamed VMEbus. 
Since then the VMEbus specifications have been refined and standardized by IEEE, ANSI, and VITA. The 
version ANSIA^ITAl.1-1997 (VME64x), American National StandardA^MEbus International Trade 
Association, was reaffirmed in 2003 and is the basis from which further extensions to the VMEbus standard 
have been released. VME64x and follow-on extensions have included significant enhancements such are 5- 
row connectors, increased current capacity, and block transfer protocols such as 2eVME and 2eSST. There 
have also been serial fabrics introduced to enhance the parallel bus reflected in the VITA 41 VME Switched 
Serial (VXS) standard. 

The marketplace has demonstrated the open system nature of VMEbus. There are thousands of VMEbus cards 
available from a multitude of vendors. Many of these cards are computer oriented cards, based on a variety of 
processing architectures, but there are also Analog EO, Digital EO, high density switch/measure and control 
systems and other acquisition cards available which are primarily aimed at industrial processing and control. 

In the spring of 1987, technical representatives from Colorado Data Systems, Hewlett-Packard (now Agilent 
Technologies), Racal Dana, Tektronix and Wavetek formed an ad hoc committee to engineer additional 
specifications necessary for an open architecture instrumentation bus based on the VMEbus, the Eurocard 
standards and other instrumentation standards such as IEEE-488.2. In July of 1987, they announced their 
agreement to support a common architecture for VMEbus modular instruments, named the VXIbus. 

During the first year, five more companies, Brael & Kjaer, Eluke, GenRad, Keifhley Insfrumenfs and Nafional 
Insframenfs, joined fhe original five companies and fhe VXIbus Consortium was formed to furlher develop and 
promote fhe specificalion. During ifs firsl ten years, fhe VXIbus Consortium has developed approximately ten 
addendum specificalions, five revisions to fhe main specificalion and hosted many inleroperabilily testing 
workshop meetings to insure complete VXI modular compalibilily. 

There were numerous requesls for modular inslmmenlalion in fhe lale 1980's, particularly from fhe United 
Slates Deparlmenl of Defense. VXIbus was developed partially in response to lhal need. However, as 
commercial applications grew more rapidly, VXIbus responded vigorously lo fill Ihose needs led by such 
induslries as Telecommunicalion, Computer, Airline, Automation and Medical. Mililary and Aerospace usage 
continued to grow and makes up a significanl portion of fhe VXIbus markel today. As VXIbus Iracks fhe 
evolution of VMEbus, if is expected to keep pace wilh bolh Mililary and Aerospace in addition to commercial 
usage in fhe foreseeable fulure. 
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A.l MANUFACTURER ID NUMBERS 

The VXIbus specification provides a mechanism for identifying the manufacturer of every VXIbus device. 
This consists of a 12-bit manufacturer ID number (0 —> 4095) which may be read over the VMEbus (See 
Section C.2.1.1.2, "Configuration Registers"). The list of ID numbers is maintained by the VXIbus 
Consortium and is available to the public upon request. Each VXIbus device manufacturer has exactly one 
Manufacturer ID number. Numbers are assigned to manufacturers in decreasing order beginning with number 
4095. To obtain an ID number, submit the following application: 


Application for Obtaining a VXIbus 
Manufacturer's Identification Number 


Company Name:_ Date: 

Company Contact:_ 

Title or Position:_ 

Address: 


Phone Number: 
Pax Number : _ 
Email Address : 


Send to the VXIbus Consortium: 

The VXIbus Consortium 
POBox 1016 
Niwot, CO 80544-1016 

Tel: 303-652-2585 
Pax: 303-652-1444 

Contact: Bob Helsel - Executive Director 
Email: bhelsel@vxibus.org 
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A.2 VXIbus OVERVIEW 


A.2.1 Introduction 

The goal of the VXIbus is to define a technically sound modular instrument specification based on the 
VMEbus that is open to all manufacturers and is compatible with present industry standards. The VXIbus 
standard has tracked many of the enhancements made to VMEbus over the years, and that trend continues in 
order to provide System Integrators the maximum flexibility and performance in building Test Systems. 

VXIbus is an acronym for VMEbus Extensions for Instrumentation. The VXIbus specification details the 
technical requirements of VXIbus compatible components, such as mainframes, backplanes, power supplies 
and modules. Before studying the VXIbus architecture, one should become familiar with the VMEbus and its 
specifications. The non-profit organization VITA (VMEbus International Trade Association and also referred 
to as VISO or VITA Standards Organization) is the primary repository for the VMEbus standards and can be 
accessed at the following URL; http://www.vita.com . This site provides you further information of the history 
of VMEbus, its applications, its outlook in the various industries, its vendors, and types of products. 


A.2.2 VMEbus Background 

The VMEbus is an open system architecture that has been primarily focused at computer systems, though there 
are presently a number of modules offering Analog EO, Digital I/O, Data Acquisition and Control and other 
instrumentation related to industrial automation. VMEbus modules are approximately six inches deep and 
come in three heights: about four inches (3U), nine inches (6U), and twelve inches (9U). The term U refers to 
rack unit and is 1.75 inches. The VXIbus specification often refers to the first two boards as the A and B-sizes, 
respectively. The precise dimensions are specified by the Eurocard standard, which describes a family of 
printed circuit boards and their associated DIN connector locations. VMEbus modules are designed for 
0.8 inch slot-to-slot spacing. VMEbus A-size boards that are compliant to VME64x have a single 160-pin 
connector known as PI, while the VME64x compliant B-size board, referred to as 6U, includes a PI and P2 
connector. Each of these DIN connectors consists of 5 rows of 32 pins apiece on O.I inch centers. Typically, 
these boards are positioned vertically in a frame with the PI connector closest to the top. Neither the VMEbus 
nor the VXIbus mandates a physical orientation, since orientation is only an implementation issue not needed 
for compatibility. Many VMEbus and VXIbus systems are designed to accept boards horizontally. 

The VMEbus specification allows a maximum of 21 modules. However, if installed vertically in a mainframe 
intended for mounting in a standard 19 inch rack, 20 is the practical maximum. VMEbus makes no particular 
provision for an extension chassis or frame-to-frame communication. Multiple frame systems can be created 
by electrically buffering the VMEbus (at the loss of some bandwidth between cages) or by using standard data 
communication links that disguise the underlying VMEbus architecture. There are no EMC (electromagnetic 
compatibility) requirements dictated by VMEbus, either conducted or radiated, nor are there power dissipation 
limits or chassis coohng requirements. VMEbus has left these issues to the system integrator, while VXIbus 
addresses these issues more rigorously. 

Although electrically and logically similar to the Motorola 68000 microprocessor architecture, the VMEbus 
interface has been specified broadly enough that it is not dependent on any particular processor and many 
processors are already supported on VMEbus, including the Intel-based processors used for Windows 
applications. Some of the simpler VMEbus boards do not have processors at all. 

A minimum VMEbus system requires only the PI connector and uses the 3U Size A modules. All 
handshaking, arbitration and interrupt support exists on PI. PI has physically 16 data and 24 address lines. The 
P2 connector is used on 6U and 9U modules and is used to physically expand the system to 32 bits of address 
and data lines. The extra lines needed for A32 and D32 are contained on the center row (row “b”) of P2. The 
original implementation of the VMEbus used non-multiplexed buses to achieve 32 bit addresses and 32 bit data 
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transfers utilizing both PI and P2 connectors. In 1989 it was realized that both the address bus and the data bus 
could be doubled from 32 bits to 64 bits by multiplexing without requiring additional pins. The VME64 
specification brings multiplexed address and data cycles to both PI (only) and P1/P2 configurations and 
provides a variety of data transfer capabilities from single cycle 8 bit transfers to multi-cycle 64 bit transfers. 

The VMEbus only needs the center 32 pins on row “b” on the P2 connector, for the additional address and data 
lines. The 64 pins in rows “a” and “c” are left as user defined inpuf/oufpuf. These undefined pins are fypically 
used for inferface connecfions, such as allowing a module fo drive a chassis mounted connector, access an 
infernal disk drive or provide for module-to-module communication. VSB (VMEbus Subsystem Bus) is a 
sfandard "subsystem bus" fhaf has defined P2 as an addifional communication pafh for up to six modules. 
Multiple VSBs may exisf wifhin any one VMEbus sysfem. This is imporfanf to nofe, because VXIbus defines 
a subsystem of up to fhirfeen modules and, like VSB, multiple VXIbus subsystems may exisf wifhin any one 
VXIbus system. 


VME64x compafibilify requires using a 160 pin connector for bofh fhe PI/JI and P2/J2 connector pairs. The 
160 pin connecfor adds fwo more 32 pin rows over fhe original 96 pin VMEbus connectors. These added rows 
are called fhe "z" row and "d" row. The “z” row is adjacenf to fhe “a” row and fhe “d” row is adjacenf fhe “c” 
row. Mechanical placemenl of fhe 160 pin connectors on VME64x boards and on fhe VME64x backplanes is 
defined in IEEE I lOI. 10. There are a number of pins on the “z” and “d” rows that are defined by the VME64x 
standard related to power supplies, grounds, and signals used for new block transfer protocols. 


VMEbus parallel operations were enhanced by two new protocols called 2eVME and 2eSST, which increase the 
performance of block transfers. 2eVME (Two Edge VME) doubled the theoretical bandwidth of the VMEbus to 
160Mbytes/sec, as compared to the 4-edge VME64 transfers. Throughput for this protocol was still limited by Slave 
handshaking. 2eSST, which stands for Two Edge Source Synchronous Transfer, defines three new transfers rates 
for the VMEbus that are based upon source synchronous transfer technology. The new transfer rates are 160 MB/s, 
267 MB/s and 320 MB/s. The 2eSST protocol also provides for broadcast data transfers. A broadcast data transfer 
allows the master to transfer the same data to multiple slaves with a single transfer instead of having to repeat the 
transfer over and over again to each slave. 


VME64x also introduced the PO/JO connector, located between the PI and P2 connectors, with the intent of the 
providing a new means for high speed serial connections to complement the VME parallel bus. The VME 
Switched Serial (VXS) base standard defines physical features that enable high speed communication in a 
VMEbus compatible system. The VXS system consists of payload boards, switch boards and a backplane 
board. The new features include the addition of a high speed connector to the VME64x payload board in the 
PO/JO position, alignment and keying, an entirely new Eurocard format board with many high speed connectors 
which may act as a switch, and the backplane/chassis infrastructure needed for support. 


A.2.3 The VXIbus Extensions 


VXIbus is an extension of the VMEbus architecture that provides more real estate on modules, shielding and 
isolation, analog power supplies and specifications for low-noise power generation, and cooling to achieve the 
best measurement performance in low-level analog and high power level apphcations. 

VXIbus retains pins defined by the VMEbus on the PI and P2 160-pin connectors. VXIbus includes the A and 
B card sizes and these modules remain VMEbus compatible, although it is more common to use VMEbus to 
VXIbus adapters in order to access additional features and functionality available in VXIbus. Substantial 
additions of VXIbus to the VMEbus specification oriented towards instrumentation can best be described as an 
electromechanical superset and a logical subset. 

The additional VMEbus enhancements provided VXIbus the opportunity for higher throughput, increased 
power, and better synchronization. These are achieved primarily by adopting the following VMEbus 
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enhancements: ANSI/VITA 1.1-1994 (VME64), ANSWITA 1.1-1997 (VMEMx), ANSEVITA 1.5-2003 
(2eSST), ANSWITA 4I.0x-2006 (VXS Core), and VITA 41.6 (Control Plane on VXS). 

VXIbus picks up the defined enhancements of adding the 5-row P1/P2 connectors and Two Edge Source 
Synchronous Transfer (2eSST) and 2eVME to drive the parallel bus to a theoretical rate of 320Mbytes/second. 
Throughput is also increased dramatically with the addition of VMEbus Switched Serial, or VXS. VXS 
introduces new features into the existing VXIbus technology base and offers distinct improvements to the 
architecture for new system designs. It adds high speed serial fabric technology in a fashion that does not 
require a revolutionary change in VXIbus system architecture. This allows the VXIbus to remain backward 
compatible with previous VXIbus modules. The extension of the existing bus with the PO/JO connectors allow 
the usage of high-speed serial buses like Gigabit Ethernet and PCI Express for high-speed module-to-module 
communication in a VXIbus system. These capabilities are important for next-generation applications such as a 
Down Converter and Digitizer communicating directly with each other instead of through the Slot 0 controller. 

Increased power, additional power supply voltages, greater signal integrity, and synchronization are achieved 
with the extension of the existing 3-row connectors to 5-row - where more pins are defined by VXIbus to 
achieve more current for existing supplies. Additional ground returns lower signal coupling/interference and 
achieve better impedance control. The addition of 3.3V and the other eight external auxiliary supply lines 
avoid using precious module real estate for power supply generation. Local bus is expanded and UC signal 
lines permit control of backplane resources. Synchronization is achieved with the addition of lOOMHz Clock 
and Sync lines that are backplane buffered and provide a low inter-module skew. 

Although significantly improved bandwidth, increased power, and triggering/synchronization are essential to 
new high speed applications, maintaining backwards compatibility with existing VXIbus modules is of critical 
importance. The inner three rows (“a”, “b”, and “c”) of PI and P2 will not change, and the new 5-row 
connector will not interfere with legacy three-row connectors on legacy VXI modules, unless those modules 
currently make use of specialized shielding. The new PO connector fits between PI and P2 without interfering 
with the fit of pre-VXIbus 4.0 modules. 

A.2.3.1 VXIbus MODULES 

VXIbus has added two Eurocard module sizes of about 13 inch depth referred to as the C and D-sizes. These 
modules are 9 and 14 inches high, respectively, and are placed on 1.2 inch centers instead of the 0.8 inch 
centers of VMEbus. The C Eurocard is the same height as the VMEbus B-size board and may sport both the 
PI and P2 connectors. The D-size module is a triple high Eurocard that may include a P3 connector in addition 
to PI and P2. The 1.2 inch module width allows feasible implementation of high density instrumentation 
modules while allowing enough space for shielding both sides of a module and inserting an optional chassis 
shield. It also has the added benefit of allowing a high degree of compatibility with the shorter and narrower A 
and B-sizes by allowing them to be mounted on full length board carriers or adapters. These carriers/adapters 
may also shield the sides of standard VMEbus cards, giving them a high degree of electromagnetic 
compatibility with VXIbus systems. 

NOTE: Beginning with VXIbus 4.0, D-sized modules are deprecated in the specification. 

A.2.3.2 VXIbus SUBSYSTEMS 

A VXIbus system may have up to 256 devices, including one or more VXIbus subsystems. A VXIbus 
subsystem consists of a central timing module referred to as Slot 0 with up to twelve additional instrument 
modules. Pins on all rows of PI, P2 and P3 are completely defined in a VXIbus subsystem. These thirteen 
modules conveniently fill a standard 19 inch cabinet when mounted vertically on 1.2 inch centers. Many 
VXIbus systems will consist only of a single frame with these thirteen modules. A common configuration will 
load the Slot 0 module with either an embedded computer or and interface module to an external computer. 
The VXIbus mandated timing generation and the VMEbus required system controller functions are handled by 
this Slot 0 module. As an embedded computer, that module has direct access to the VXIbus backplane. As an 
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interface module, backplane control is achieved indirectly using a MXI interface or through common I/O data 
communication ports such as IEEE 1394, Ethernet, IEEE 488, or RS-232. Slot 0 may also include optional 
instrumentation. The other slot positions are general purpose for the user to mix and match modules. A single 
VXIbus subsystem may have less than 12 additional slots, but it may not have more. Any combination of 
VXIbus subsystems may exist within a VXIbus system. Eor instance, one VXIbus system may consist of a 
frame with one Slot 0 and twelve VXIbus modules extended to another frame that has a Slot 0 adjacent to three 
instrument slots, and another Slot 0 with five instrument slots and four standard VMEbus slots of undefined 
P2. 


A.2.3.2.1 PI and P2 Connector Definition 

A VXIbus subsystem defines all PI and P2 pins on all 5 rows of the 160-pin connectors. Pins not specifically 
defined by the VME64x standard are specified by VXIbus. The VXIbus PI and P2 add the following pin 
definitions to PI and P2: 

• lOMHz ECU clock 

• lOOMHz LVDS Clock and Sync 

• ECL supply voltages 

• Analog supply voltages 

• ECL and TTL trigger lines 

• Low-skew star triggering 

• Analog summing bus 

• Module identification 

• Daisy-chain local bus 

• Additional power and ground pins for higher current and for reducing noise coupling on backplane 
signal lines. 

The trigger lines serve primarily as resources for signaling between instruments in a VXIbus subsystem, while 
the local bus lines are preferred for use within a multiple module instrument set (adjacent slots). The daisy 
chain local bus use is left to the module manufacturer to define, and several classes of electrical signals are 
permitted. Allowed signals are TTL, ECL, low voltage analog and analog up to 42 volts. A keying 
mechanism near the faceplate indicating that module's local bus class prevents incompatible classes from 
accidentally being placed adjacently and potentially causing a destructive condition. Typical uses of the local 
bus include creating an internal analog bus or a chain of serial digital signal processors. 


A.2.3.2.2. P3 Connector Definition 

The VXIbus P3 connector adds many of the same resource types as described for P2, but is aimed at higher 
performance instrumentation. Included on P3 are 100 MHz clock and sync signals, additional power pins of 
the same supply voltages, more ECL trigger lines and twenty-four additional lines (48 pins) of daisy chain 
local bus. Also defined on P3 is a "star" trigger system where precision ECL trigger signals are routed through 
Slot 0 acting as a cross point switch. This allows very precisely matched trigger timing between modules 
regardless of module position. 

Note that the VXIbus spec is no longer updating the P3 connector and functionality. Much of the functionality 
is now part of the VXIbus 4.0 specification. 


A.2.3.2.3. PO Connector Definition 

The longevity of the VXIbus can be enhanced by maintaining backward compatibility and adopting new 
technology that enhances its ability to deliver higher test system throughput and flexibility. When 
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evolutionary changes are not able to meet growing demands of test system throughput and flexibility, the 
interconnect between modules can to be refreshed. This should only be done while minimizing the negative 
effects on the established VXIbus ecosystem of products. The addition of the PO connector is to receive the 
maximum benefit from the new technology infusion while maintaining backward compatibility. 

Open switched serial technologies provide many benefits over the technologies currently employed in the 
VXIbus parallel data plane. The intent of adding the PO connector is to adopt a data plane interconnect using 
switched serial technologies that are readily available and provide many of the following benefits: 

• Higher transaction bandwidth 

• Higher aggregate bandwidth 

• Lower link latency 

• Less contention for the interconnect medium 

• Increased scalability 

• Less routing real estate consumed 

There are many candidate technologies for a switched serial interconnect, and this standard may illustrate use 
of this capability with examples such as PCIe or Gigabit Ethernet. However, the VXIbus standard is only 
specifying the ANSEVITA VXS 41.0 standard infrastructure for module interconnect and how that should be 
oriented on VXIbus modules and backplane. 

The addition of the PO connector becomes coincident with the PI VXIbus and is not intended to be exclusive 
of that connector. The VXIbus standard requires all modules to be identified and managed by the Slot 0 
controller and Resource Manager. However, once established within the VXIbus system, the switched serial 
interconnect between cooperating modules allows direct peer-to-peer communication without the requirement 
for bus management by the Slot 0 controller. 
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A.2.3.3 VXIbus SYSTEM ARCHITECTURE 

The VXIbus device protocols define how modules are granted non-conflicting portions of the VMEbus address 
space. A device is typically a single module, but this is not required. Several devices may exist on a single 
module and a single device may consist of multiple modules. 256 devices may exist in any one VXIbus 
system and are referred to by logical device addresses ranging from 0 to 255. A VXIbus system configuration 
space is defined in the upper I6k of the 64k AI6 address space. Each device is granted a total of 64 bytes in 
this space, which is sufficient for many of the simpler devices. Devices requiring additional address space 
have their address requirements readable in a defined register in the A16 address space. A "resource manager" 
reads this value shortly after power-on and then assigns the requested memory space by writing the module's 
new VMEbus address into the device's offset register. This method positions a device's additional memory 
space in the A24 (16 Mbyte), A32 (4 Gbyte), or A64 (18 Ebyte) address space. If present day VMEbus cards 
are used in a system, the resource manager must position the VXIbus devices around the space taken by the 
standard VMEbus cards. 


A.2.3.4 VXIbus SPECIFICATION STRUCTURE 

In structure, the VXIbus specification parallels much of the VMEbus specifications. In many cases, more 
detailed information can be found about VMEbus cycles and other topics like block transfer protocols. Some 
VXIbus specification sections have the same titles as the VMEbus chapters. Care has been taken to keep those 
references up-to-date. Other sections are devoted to topics not addressed by the VMEbus specification. 

The VXIbus document contains more than just the rales needed for VXIbus compliance. Included are design 
tips and suggestions added to help the designer create compatible components. The same format of RULES, 
RECOMMENDATIONS, SUGGESTIONS and OBSERVATIONS as VMEbus is used. 

Refer to the beginning of this document for information on permissions afforded the VXIbus Consortium in 
leveraging and re-using VMEbus descriptions, terminology, and illustrations. 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 



Section A: INTRODUCTION 


Page 9 


A.3 DOCUMENT STRUCTURE 

This document is organized in sections, with each section discussing a particular independent level of the 
implementation. In the event where a section parallels another standard document (such as VMEbus) 
subsections will have corresponding numbers. Several appendices, containing clarifications and extensions, 
follow the body of the specification. 


A.4 SPECIEICATION OBJECTIVES 

This document defines a set of RULES and RECOMMENDATIONS for constructing a component which 

will interface to the VXIbus Family. The specifications cover the complete spectrum from basic hardware 

issues such as card dimensions to recommendations for communications protocols. This specification has the 

following objectives: 

1. To allow communication among devices in an unambiguous fashion. 

2. To allow for physical size reduction of standard Rack&stack instrumentation systems. 

3. To allow for software cost reduction in test system integration by the use of common interfaces to 
analogous capabilities. 

4. To provide higher system throughput for test systems through the use of higher bandwidth channels for 
inter-device communication and the use of new protocols specifically designed to enhance throughput. 

5. To provide test equipment which could be used in military lAC (Instrument on a Card) systems. 

6. To provide the ability to implement new functionality in test systems through the use of virtual 
instruments. 

7. To define how fo implemenf Mulfi-module Insfrumenfs wifhin fhe framework of fhis specificafion. 
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A.5 DEFINITION of TERMS 

Throughout this document you will see the following headings on sentences or paragraphs. These headings 
identify the contents of the paragraph. Any text which appears without heading should be considered as 
description of the specification. 


RULE: Rules SHALL be followed to ensure compatibility for cards in the system. A rule is characterized by 
the use of the words SHALL and SHALL NOT. These words are not used for any other purpose other than 
stating rules. 

RECOMMENDATION: Recommendations consist of advice to implementers which will affect the usability 
of the final device. Discussions of particular hardware to enhance throughput would fall under a 
recommendation. These should be followed to avoid problems and to obtain optimum performance. 

SUGGESTION: A suggestion contains advice which is helpful but not vital. The reader is encouraged to 
consider the advice before discarding it. Suggestions are included to help the novice designer with areas of 
design that can be problematic. 

PERMISSION: Permissions are included to clarify the areas of the specification that are not specifically 
prohibited. Permissions reassure the reader that a certain approach is acceptable and will cause no problems. 
The word MAY is reserved for indicating permissions. 

OBSERVATION: Observations spell out implications of rules and bring attention to things that might 
otherwise be overlooked. They also give the rationale behind certain rales, so that the reader understands why 
the rale must be followed. 

DEPRECATED: A deprecated element or attribute is one that has been outdated by newer constructs. 
Deprecated elements may become obsolete in future versions of this specification. Deprecated sections or 
content will continue to be supported for reasons of backward compatibility. 
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B. VXIbus IMPLEMENTATION of VMEbus SPECS 


This document describes additions to and recommendations for the VMEbus and is organized in a parallel 
fashion to the ANSEVITAVME64/VME64x/2eSSTA^XS specification documents Sections B.l - B.7 

are additions to the corresponding VME64 Chapters 1-7. Section B.8 is unique to VXIbus and has no 
corresponding VME64 chapter. Section B.l I is an addition to Chapter II of VME64x. Section B.l2 is an 
addition to the Chapter 2 of 2eSST. Section B.l3 covers the addition of VMEbus Switch Serial (VXS). 

Rather than creating complete redundancy in the VXIbus specification, the differences and enhancements are 
the focus, and the reader is encouraged to refer to the VMEbus documents which often include a lot of detail 
about bus and register operations in the VMEbus environment. In some cases, it is necessary to provide some 
level of redundancy in order to make the features and topics clear. 

As indicated below in Section B.2, there are various capabilities in VMEbus that are not supported in VXIbus. 
VXIbus was designed for instrumentation test systems and therefore does not support many User Defined or 
special features that may be used by System Integrator in creating custom solutions for varied industries. 
VXIbus specifies all modes of operations — pin assignments, cooling, EMI, address modes, etc. It also includes 
a Resource Manager that identifies and configures various modules and prepares them for operating within the 
behavior of the VXIbus environment. 


B.l. INTRODUCTION 

The intent of the VXIbus Implementation of the VMEbus specifications is to produce an electro-mechanical 
superset and logical subset of the VMEbus specifications in order to establish compatibility for all VXIbus 
systems. It is expected that most boards designed to the VMEbus specification will be compatible with this 
implementation mechanically and electrically. However, a subset of VMEbus Protocols relating to data 
transfer, arbitration and interrupts has been specified and may limit the utility of some standard VMEbus 
products in a VXIbus system. Mechanical extensions and VXIbus Adapters allow for a superset of board sizes. 


B.2 DATA TRANSFER BUS 


B.2.1 Address Modifiers 

RECOMMENDATION B.2.1: 

The following VMEbus address modifiers should not be used in VXIbus systems. In some cases, the 
functionality of these features already existed using a different implementation technique in the VXIbus. 
Explanations are included for clarity: 

• 04i6, 05i6, 2Ci6, 32i6, 35i 6 (Lock commands). 

• 10i6 — 1 Fi 6 (User Defined in VMEbus). User Defined modes not allowed in VXIbus. 

• 20i 6 with XAM codes, 21 le, 22i6 (6U 2eSST Broadcast Transfers). XAM codes 11 le, I2i6,01 le, and 
02 i 6 are supported with the addition 2eSST, 2eVME, and the 160-bin PI/P2 connectors. 

• 21 16 with XAM codes, 21 le, 22i6 (3U 2eSST Broadcast Transfers). XAM codes 11 le, I2i6,01 le, and 
02 i 6 are supported with the addition 2eSST, 2eVME, and the 160-bin PI/P2 connectors. 
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• 2Fi 6 (CR/CSR). VXIbus does not support these Control and Status registers. Instead, it uses AI6 
registers defined for each module for initialization and configuration. 

• 34i6, 37 16 (A40 transfers). 


OBSERVATION B.2.1: 

The intent of the preceding restrictions is to increase interoperability between masters and slaves in VXIbus 
systems. 

OBSERVATION B.2.2: 

XAM codes are “Extended Address Modifier codes”. These are defined in VME64x and in 2eSST,^®^ 
(ANSEVITA 1.5-2003), they are used to select 2eVME or 2eSST cycles on the backplane. VXIbus supports 
both 3U and 6U protocols for 2eVME and 2eSST, except for broadcast. 

B.2.2 DTACK*, BERR*, RESP* and RETRY* Operation 

For highest performance, VXIbus slaves should respond to register accesses as fast as possible, by 
sourcing/accepting data and asserting DTACK* immediately. Sometimes a register may be busy, temporarily 
unable to source or accept data. In this case the slave should assert RETRY*(6U modules) or RESP* (3U 
modules) to indicate the busy condition to the bus master. If either device does not support RETRY* or 
RESP*, the slave may wait for up to 20 //s for the register to become ready. If the register becomes ready 
within this time, the slave will source/accept the data and assert DTACK*. Otherwise, it will end the cycle by 
asserting BERR*. 

For example, in some applications modules collect a random amount of data, ranging from zero bytes to many 
kilobytes. Masters reading this data from the slave have no prior knowledge as to the amount of data being 
retrieved. Slaves can terminate or suspend the block transfer at any time. For 6U modules that have both PI 
and P2 160-pin connectors, termination is affected by asserting RETR* and then asserting BERR*. For 3U 
modules that only have the PI 160-pin connector, RESP* is used instead of RETRY*. Likewise, for 
suspension of a transfer, 6U modules use the RETRY* and toggle DTACK*, while 3U modules use RESP* 
and toggle DTACK*. 


VXIbus slaves are not allowed to exhibit deadlocks, when a register is not accessible to another VXIbus master 
because the slave device itself is waiting to become bus master. Any such conflict is to be resolved in favor of 
the current bus master. 

RECOMMENDATION B.2.2: 

During an attempted access of one of its implemented registers, a VXIbus SLAVE should normally drive 
DTACK* low within 100 ns after a data strobe goes low. 

OBSERVATION B.2.3: 

The intent of the preceding recommendation is to maximize overall system performance by encouraging 
designers to implement all low level handshaking in fast hardware. 

RECOMMENDATION B.2.3: 

During an attempted access of a busy register, a VXIbus SLAVE should drive RETRY* or RESP* low within 
100 ns after a data strobe goes low. 

RULE B.2.1: 

During an attempted access of one of its implemented registers, a VXIbus SLAVE SHALL drive DTACK* or 
BERR* low within 20 //s after a data strobe goes low, if the cycle has not already been terminated by the 
VXIbus MASTER in response to a RETRY* or RESP* assertion. 
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RULE B.2.2: 

Addressed VXIbus SLAVES SHALL release DTACK*, BERR*, RESP*, and RETRY* high within 5 jus after 
the data strobe(s) goes high. 

RECOMMENDATION B.2.4: 

Addressed VXIbus SLAVES should release DTACK*, BERR*, RESP* and RETRY* high within 0.1 /us after 
the data strobe(s) goes high. 

RULE B.2.3: 

During an access to a deadlocked register, the VXIbus SLAVE SHALL terminate its own contention for bus 
mastership and allow the current VXIbus MASTER immediate access to the deadlocked register. 

RECOMMENDATION B.2.5: 

A SLAVE should implement the Rescinding DTACK* described in Section 2.2.4.3.1 of the VME64 
specification, ANSEVITA 1.0-1994 (R2002). 

OBSERVATION B.2.4: 

Devices participating in 2eVME and 2eSST transactions are required to meet the additional timing 
requirements called out in Section B. 11, “2eVME Protocol.”, and Section B. 12, “2eSST Protocol.” 

B.2.3 CR/CSRs 

The VME64 specification (see Section 2.3.12) defines an address space accessing VME64 Configurafion 
ROM / Confrol and Sfafus Regisfer (CR/CSR) resources. This CR/CSR capabilify has overlapping 
funclionalily wifh fhe Configurafion and Communicafion regisfers defined in Secfion C of fhis specificafion. 
The VXIbus specificafion does nof include fhese CR/CSRs. 

RULE B.2.4: 

VXIbus devices SHALL NOT rely on VME64 CR/CSRs for proper operafion. 

B.2.4 Bus Timer Operation 

RULE B.2.5: 

The BUS TIMER SHALL be BTO (>100). BTO unifs are in ps. 

OBSERVATION B.2.5: 

The BTO(IOO) capabilify minimum is fo allow for chassis fo chassis communicafion. There is a pofenfial for 
each chassis fo fake up fo 20 ps fo respond fo a dafa fransfer. 

B.2.5 Compatibility with Pre-VXIbus 4.0 Modules 

Pre-VXIbus 4.0 modules wifh 3-row connectors can be used in mainframes wifh 3-row and 5-row connectors. 
Modules wifh 5-row connector - that don’t utilize pins from rows “z” and “d” - can be used in mainframes 
with 3-row or 5-row connectors. However, if pins are use in those two outer rows, then the module needs 
VXIbus 4.0 compliant mainframe with 5-row connectors. 

Some vendors supply additional shielding as an option to their modules. This shielding connects the outside of 
the 3-row connector and interfaces with the backplane ground. Modules with the shielding will not fit into 
VXIbus 4.0 backplanes without modification. The shielding will have to be removed in order to fit into the 5 - 
row connector. Or, the mainframe vendor may supply some 3-row slots for backward compatibility. Refer to 
Appendix III for more information on backwards compatibility. 
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B.3 DATA TRANSFER BUS ARBITRATION 

RULE B.3.1: 

The BUS GRANT daisy-chain lines SHALL be used or passed by all single boards and board assemblies. 

RECOMMENDATION B.3.1: 

The arbiter should implement priority based arbitration between the 4 Bus Request/Grant levels. 


B.4 PRIORITY INTERRUPT 

RULE B.4.1: 

The INTERRUPT ACKNOWLEDGE daisy-chain lines SHALL be used or passed by all single boards and 
board assemblies. 


B.5 UTILITIES 


B.5.1 Power Monitor 

The POWER MONITOR is a VME64 function which asserts the SYSRESET* line at power-on and asserts 
both the ACE AIL* and SYSRESET* lines immediately prior to power-removal. Although this is an optional 
VME64 capability which may reside on the system controller board, it is a required VXIbus capability closely 
linked to the mainframe power supply. Therefore, each mainframe is required to provide this function. 

RULE B.5.1: 

Every VXIbus mainframe SHALL provide a VME64 POWER MONITOR. 

RECOMMENDATION B.5.1: 

A power monitor should drive ACEAIL* low a minimum of 8 ms before driving SYSRESET* low and a 
minimum of 10 ms before -i-5 VDC power drops below 4.875 volts, when a power failure is detected. See 
Eigure 5-4 of the VME64 specification. 

The VME64 specification defines relationships between the SYSRESET*, ACEAIL* and -i-5 V signals. In 
VXIbus systems, relationships to other signals are also important. 

RULE B.5.2: 

At power-on, all VXIbus defined power supplies SHALL be within specification at least 2 milliseconds before 
SYSRESET* transitions to the unasserted (High) state, under all rated load conditions. 

OBSERVATION B.5.1: 

The VME64 specification requires that the -i-5 V power supply be within specification at least 200 ms before 
SYSRESET* becomes unasserted. 

RECOMMENDATION B.5.2: 

A module that requires specific sequencing of the power supplies should provide its own power sequencer. 
Such a sequencer should start its operation after it detects SYSRESET* unasserted. 

OBSERVATION B.5.2: 

Module designers can not depend on the transient behaviors of VXIbus mainframes during power-up. The 
relative sequencing, slew rates, monotonic transitions, etc of the various power supplies are not specified. 

RULE B.5.3: 

At power-on, the SYSCLK and CLKIO signals SHALL be within specification before SYSRESET* 
transitions to the unasserted (High) state. 
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OBSERVATION B.5.3: 

The clock generation circuits are guaranteed at least 2 milliseconds for stabilization in the interval after the 
power supplies are within specification and before SYSRESET* becomes unasserted. 

PERMISSION B.5.1: 

A Slot 0 module that requires more than 2 milliseconds for its SYSCLK and CLKIO generators to stabilize 
MAY assert SYSRESET* during power-on sequencing until the clock signals are within specification. 

B.5.2 Power Pins 

See Section B.8, "EMC and System Power", for power pin specifications. 


B.5.3 Auto Slot ID 

VME64 defines a mechanism to determine the relative slot positions of cards and assign CSR base addresses to 
those cards. The Auto ID Slave uses a level 2, DOS (O) Interrupter along with additional board specific 
hardware to obtain the CR/CSR base address. This Auto Slot ID function is incompatible with VXIbus 
requirements. 

RULE B.5.4: 

VXIbus devices SHALL NOT implement the VME64 Auto Slot ID function. 

OBSERVATION B.5.4: 

VXIbus uses MODID signals to determine the slot positions of modules (See Section B.6.2.2, "MODID 
Lines"). VXIbus also defines a mechanism for assigning logical addresses, based on slot positions (See 
Section E, "Dynamic Configuration"). 

B.5.4 Auto System Coutroller 

VME64 defines an aufomafic means for a device fo defecf whefher if is in VMEbus Slof 1, allowing if to 
aufomalically enable ifs sysfem confroller functions. 

OBSERVATION B.5.5: 

The VME64 system confroller and VXIbus Slof 0 functions usually reside in fhe same module/slof. However, 
fhe VXIbus specification allows fhe implemenfafion of segmented backplanes, which may separate fhese 
functions. 

PERMISSION B.5.2: 

VXIbus devices MAY implemenf fhe VME64 Auto System Confroller deteclion scheme. 

RECOMMENDATION B.5.3: 

VXIbus modules should nol use fhe VME64 Auto System Confroller detection to enable/disable Slof 0 
functions, nor use fhe VXIbus MODID signals to enable/disable VME64 system confroller functions. 

B.5.5 Slot Geographical Address Pius 

Slof geographical addressing as defined in VME64x allows modules to automatically identify into which 
VME64x backplane slof if is plugged. Based on fhaf information, soflware can automatically configure fhe 
boards for slof specific functionalify. Inifializafion and configuration of fhe CR/CSR’s is an extension of fhe 
capabilify in VME64x. VXIbus has ifs own mechanism for identification and configurafion of VXIbus 
modules, as defined in Section B.6.2.2, "MODID Lines" and Section C.4.I.I DEVICE IDENTIEICATION. 

RULE B.5.5: 

VXIbus devices SHALL NOT use fhe geographical address pins defined by VME64x fo deferntine fhe slof 
position. 
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PERMISSION B.5.3: 

VXIbus devices MAY use the geographical address pins to determine a VXI-1 4.0 compatible backplane. 

B.6 ELECTRICAL SPECIFICATIONS 

RULE B.6.1: 

All conductors on PI, P2 and P3 SHALL meet the requirements of Chapter 6.1 of the VME64 (VITA 1-1994) 
specification. 

RULE B.6.1.1: 

In order to meet backplane shielding requirements, the lEC 61076-4 family of 160-pin connectors SHALL be 
used for PI, P2 and P3. See Rules B.7.44-49 and Recommendation B.7.11. 

B.6.1 The VXIbus Subsystem PI Connector 

All the signals on the 160-pin PI connector are defined by the VME64 and VME64x specifications. Only pins 
marked as "User Defined" or UD in the VMEbus standards were used to enhance existing VXIbus system 
components or introduce further extensions. See TABLE B.1.1 for PI Pin Definitions: Slots 0-12. 

RULE B.6.1.2: 

The fourteen RsrvBus pins, the five test and maintenance bus (MPR, MCLK, MSD, MMD, and MCTL) pins 
and the RESP* pin SHALL be bused and terminated on VXI-1 revision 4.0 backplanes that implement a 160- 
pin connector for J1 in the same fashion and have the same rules as the other bused signals defined in this 
standard. 

RULE B.6.1.3: 

The RsvBus (reserved bused) pins are reserved for future use. Modules SHALL NOT make any 
connection to RsvBus pins. 

RECOMMENDATION B.6.1.0: 

The five test and maintenance bus signal lines (MPR, MCLK, MSD, MMD & MCTL) are reserved. VXIbus 
modules SHALL NOT make any connection to those pins. 

RULE B.6.1.4: 

The LEI* (Live Insertion/Input) and LEO* (Live Insertion/Output) pins SHALL be reserved for 
future definition by the VXIbus consortium. 


OBSERVATION B.6.1.1: 

The LEI*, LEO* and RsvU pins are not bused, but just feed through the backplane. The VPC (1) and GND (1) 
pins are MEBL (mate-first — break-last) pins. 

OBSERVATION B.6.1.2: 

The VPC (1) and GND (1) pins are MEBL (mate-first - break-last) pins. 

RULE B.6.1.5 

The 6 geographical address pins (GAO*, GAl*, GA2*, GA3*, GA4* and GAP*) SHALL be tied 
to ground or left open (floating) on the backplane connector as defined by the ANSEVITA 
1.1-1997 (VME64x) standard. Rule 3.16. 

RULE B.6.1.6 

VXIbus modules SHALL NOT use the geographical address pins to enable/disable Slot-0 functions. 
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B.6.2 The VXIbus Subsystem P2 Connector 

In the VME64 bus documentation, rows “a” and “c” are User Defined. The VXIbus subsystem bus defines 
these rows. Likewise, rows “z” and “d” of the 160-pin connector are also defined by the VXIbus system for 
instrumentation use. The center row “b” signals are defined by VME64. Alternate definitions of the outer four 
rows of P2 are permitted in VXIbus systems (not VXIbus subsystems) with a "Segmented Backplane" 
architecture where other VME64 subsystem buses, such as VSB, may exist. A VXIbus subsystem bus consists 
of a system resource module defined as Slot 0 with up to twelve adjacent modules in increasing slot numbers. 
VXIbus and VXIbus subsystem bus are used interchangeably in this section of the VXIbus specification. 

Only pins marked as "User Defined" or UD in the VMEbus standards were used to enhance existing VXIbus 
system components or introduce further extensions. RsvVXI marked pins are reserved for future use by the 
VXIbus consortium. 

The VXIbus P2 160-pin connector rows “a” and “c” deliver resources to modules particularly oriented toward 
instrumentation. 

-5.2 V, -2 V, +24 V and additional +5 V power. 

10 MHz differential clock. 

2 parallel ECL trigger lines. 

8 parallel TTL trigger lines. 

Module identification pin. 

12 lines of manufacturer defined local bus lines that connect to adjacent modules. 

50 Q terminated analog summing bus. 

The VXIbus P2 160-pin connector rows “z” and “d” provide additional resources to modules oriented toward 
instrumentation: 

43 ground return pins (38 plus 5 MEBL). This improves the signal quality for 2eSST transfers. 

10 pins for +3.3V. Reduces power consumption and helps save real estate on modules. 

5 pins for +5V (2 plus 3 VPC). 

1 pin each for +12V, -12V, +24V and -24V supplies 

8 lines of manufacturer defined local bus lines that connect to adjacent modules. 

4 pairs of Star Trigger lines, one for outputting a Star Trigger and three pairs for input for slots 1-12. 

4 auxiliary power pins (+V3/-V3, +V4/-V4) which augment the VME64x-defined +V1/-V1, +V2/-V2 
on the PI connector (row z) for supplying four additional voltages to modules that connect to external 
power supplies through the VXIbus backplane. 

The Slot 0 module serves as a system resource and has a modified P2 functionality for central handling of the 
module identification pins. The Slot 0 Module, while providing these common resources, may also contain 
other devices and instrumentation. 
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PIN 

ROW ‘z’ 

ROW ‘a’ 

ROW ‘b’ 

ROW ‘c’ 

ROW ‘d’ 

NUMBER 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 


MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

1 

MPR 

DOO 

BBSY* 

D08 

VPC (1) 

2 

GND 

D01 

BCLR* 

D09 

GND (1) 

3 

MCLK 

D02 

ACFAIL* 

DIO 

+V1 

4 

GND 

D03 

BGOIN* 

Dll 

+V2 

5 

MSD 

D04 

BGOOUT* 

D12 

RsvU 

6 

GND 

D05 

BG1IN* 

D13 

-VI 

7 

MMD 

D06 

BG10UT* 

D14 

-V2 

8 

GND 

D07 

BG2IN* 

D15 

RsvU 

9 

MCTL 

GND 

BG20UT* 

GND 

GAP* 

10 

GND 

SYSCLK 

BG3IN* 

SYSFAIL* 

GAO* 

11 

RESP* 

GND 

BG30UT* 

BERR* 

GA1* 

12 

GND 

DS1* 

BRO* 

SYSRESET* 

-1-3.3 V 

13 

RsrvBus 

DSO* 

BR1* 

LWORD* 

GA2* 

14 

GND 

WRITE* 

BR2* 

AM5 

-1-3.3 V 

15 

RsrvBus 

GND 

BR3* 

A23 

GA3* 

16 

GND 

DTACK* 

AMO 

A22 

-1-3.3 V 

17 

RsrvBus 

GND 

AMI 

A21 

GA4* 

18 

GND 

AS* 

AM2 

A20 

-1-3.3 V 

19 

RsrvBus 

GND 

AM3 

A19 

RsrvBus 

20 

GND 

lACK* 

GND 

A18 

-1-3.3 V 

21 

RsrvBus 

lACKIN* 

SERA 

A17 

RsrvBus 

22 

GND 

lACKOUT* 

SERB 

A16 

-1-3.3 V 

23 

RsrvBus 

AM4 

GND 

A15 

RsrvBus 

24 

GND 

A07 

IRQ7* 

A14 

-1-3.3 V 

25 

RsrvBus 

A06 

IRQ6* 

A13 

RsrvBus 

26 

GND 

A05 

IRQ5* 

A12 

-1-3.3 V 

27 

RsrvBus 

A04 

IRQ4* 

All 

LI/I* 

28 

GND 

A03 

IRQ3* 

A10 

-1-3.3 V 

29 

RsrvBus 

A02 

IRQ2* 

A09 

Ll/0* 

30 

GND 

A01 

IRQ1* 

A08 

-1-3.3 V 

31 

RsrvBus 

-12V 

+5V STDBY 

+12V 

GND (1) 

32 

GND 

+5V 

+5V 

+5V 

VPC (1) 


TABLE B.l for PI Pin Definitions: Slots 0-12 
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PIN 

ROW ‘z’ 

ROW ‘a’ 

ROW ‘b’ 

ROW ‘c’ 

ROW ‘d’ 

NUMBER 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 


MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

1 

+V3 

ECLTRGO 

-I-5V 

CLK10-I- 

GND(1) 

2 

GND 

-2V 

GND 

CLK10- 

GND(1) 

3 

-V3 

ECLTRG1 

RSV1 

GND 

LCLK100-I- 

4 

GND 

GND 

A24 

-5.2V 

LCLK100- 

5 

+V4 

LBUSAOO 

A25 

LBUSCOO 

GND 

6 

GND 

LBUSA01 

A26 

LBUSC01 

LSYNC100-I- 

7 

-V4 

-5.2V 

A27 

GND 

LSYNC100- 

8 

GND 

LBUSA02 

A28 

LBUSC02 

GND 

9 

LBUSA12 

LBUSA03 

A29 

LBUSC03 

GND 

10 

GND 

GND 

A30 

GND 

LBUSC12 

11 

LBUSA13 

LBUSA04 

A31 

LBUSC04 

LBUSC13 

12 

GND 

LBUSA05 

GND 

LBUSC05 

-I-5V 

13 

LBUSA14 

-5.2V 

-I-5V 

-2V 

LBUSC14 

14 

GND 

LBUSA06 

D16 

LBUSC06 

LBUSC15 

15 

LBUSA15 

LBUSA07 

D17 

LBUSC07 

GND 

16 

GND 

GND 

D18 

GND 

LBUSC16 

17 

LBUSA16 

LBUSA08 

D19 

LBUSC08 

LBUSC17 

18 

GND 

LBUSA09 

D20 

LBUSC09 

-I-5V 

19 

LBUSA17 

-5.2V 

D21 

-5.2V 

LBUSC18 

20 

GND 

LBUSA10 

D22 

LBUSC10 

LBUSC19 

21 

LBUSA18 

LBUSA11 

D23 

LBUSC11 

GND 

22 

GND 

GND 

GND 

GND 

GND 

23 

LBUSA19 

TTLTRGO* 

D24 

TTLTRG1* 

STRGOUT-i- 

24 

GND 

TTLTRG2* 

D25 

TTLTRG3* 

STRGOUT- 

25 

+12V 

-I-5V 

D26 

GND 

STRGINO-i- 

26 

GND 

TTLTRG4* 

D27 

TTLTRG5* 

STRGINO- 

27 

-12V 

TTLTRG6* 

D28 

TTLTRG7* 

STRGIN1-I- 

28 

GND 

GND 

D29 

GND 

STRGIN1- 

29 

+24V 

RSV2 

D30 

RSV3 

STRGIN2-I- 

30 

GND 

MODID 

D31 

GND 

STRGIN2- 

31 

-24V 

GND 

GND 

-I-24V 

GND (1) 

32 

GND 

SUMBUS 

-I-5V 

-24V 

VPC (1) 


TABLE B.1.1 for P2 Pin Definitions: Slots 1-12 
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PIN 

ROW ‘z’ 

ROW ‘a’ 

ROW ‘b’ 

ROW ‘c’ 

ROW ‘d’ 

NUMBER 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 


MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

1 

+V3 

ECLTRGO 

-I-5V 

CLK10-I- 

GND (1) 

2 

GND 

-2V 

GND 

CLK10- 

GND (1) 

3 

-V3 

ECLTRG1 

RSV1 

GND 

LCLK100-I- 

4 

GND 

GND 

A24 

-5.2V 

LCLK100- 

5 

+V4 

MODID12 

A25 

LBUSCOO 

GND 

6 

GND 

MODID11 

A26 

LBUSC01 

LSYNC100-I- 

7 

-V4 

-5.2V 

A27 

GND 

LSYNC100- 

8 

GND 

MODID10 

A28 

LBUSC02 

GND 

9 

SDAO 

MODID09 

A29 

LBUSC03 

STRGIN12-I- 

10 

GND 

GND 

A30 

GND 

STRGIN12- 

11 

SCLO 

MODID08 

A31 

LBUSC04 

STRGIN11-I- 

12 

GND 

MODID07 

GND 

LBUSC05 

STRGIN11- 

13 

SDA1 

-5.2V 

-I-5V 

-2V 

STRGIN10-I- 

14 

GND 

MODID06 

D16 

LBUSC06 

STRGIN10- 

15 

SCL1 

MODID05 

D17 

LBUSC07 

STRGIN09-I- 

16 

GND 

GND 

D18 

GND 

STRGIN09- 

17 

STRGIN04+ 

MODID04 

D19 

LBUSC08 

STRGIN08-I- 

18 

GND 

MODID03 

D20 

LBUSC09 

STRGIN08- 

19 

STRGIN04- 

-5.2V 

D21 

-5.2V 

STRGIN07-I- 

20 

GND 

MODID02 

D22 

LBUSC10 

STRGIN07- 

21 

STRGIN03+ 

MODID01 

D23 

LBUSC11 

STRGIN06-I- 

22 

GND 

GND 

GND 

GND 

STRGIN06- 

23 

STRGIN03- 

TTLTRGO* 

D24 

TTLTRG1* 

STRGIN05-I- 

24 

GND 

TTLTRG2* 

D25 

TTLTRG3* 

STRGIN05- 

25 

STRGIN02+ 

-I-5V 

D26 

GND 

STRGOUTO-i- 

26 

GND 

TTLTRG4* 

D27 

TTLTRG5* 

STRGOUTO- 

27 

STRGIN02- 

TTLTRG6* 

D28 

TTLTRG7* 

STRGOUT1-I- 

28 

GND 

GND 

D29 

GND 

STRGOUT1- 

29 

STRGIN01 + 

RSV2 

D30 

RSV3 

STRGOUT2-I- 

30 

GND 

MODIDOO 

D31 

GND 

STRGOUT2- 

31 

STRGIN01- 

GND 

GND 

-I-24V 

GND (1) 

32 

GND 

SUMBUS 

-I-5V 

-24V 

VPC (1) 


TABLE B.2 for P2 Pin Definitions: Slots 0 
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Figure B.l. CLKIO, LCLKIOO, LSYNC, MODID and LBUS backplane signal routing 
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B.6.2.1 CLKIO 

CLKIO is a 10 MHz system clock. It is sourced from Slot 0 and distributed to Slots 1 -12 on P2. The Slot 0 
output is differential ECL. It is buffered on the backplane and distributed to each module slot as a single 
source, single destination differential ECL signal. The CLKIO is individually buffered on the backplane for 
each slot position to provide a high level of inter-module isolation and relax the loading rules for modules. 
See Eigure B.l. 

RULE B.6.2: 

The CLKIO frequency sourced from Slot 0 SHALL be 10 MHz. Its accuracy SHALL be equal to or better 
than +100 ppm (0.01%), over its specified operating temperature and time. 

RECOMMENDATION B.6.1: 

A Slot 0 module should allow CLKIO to be derived from an external frequency source. 

OBSERVATION B.6.2: 

An external frequency source would permit the use of an accurate frequency reference, such as a Rubidium 
Standard and would facilitate synchronization of multiple VXIbus mainframes. 

RULE B.6.3: 

CLKIO duty cycle SHALL be 50% +5% when measured at the 50% transition level. 

RULE B.6.4: 

IF CLKIO is switched between different clock sources, 

THEN the minimum pulse width, high or low, SHALL NOT be less than 30 ns or more than 10 //s during 
switching. The minimum time between two successive transitions of the same polarity SHALL NOT be less 
than 80 ns. 

RULE B.6.5: 

Each slot's CLKIO SHALL be differentially driven by a unique backplane buffer output. 

RULE B.6.6: 

CLKIO SHALL be differentially driven onto the CLK10+ and CLKIO- pins by the module in Slot 0. 

RULE B.6.7: 

The backplane CLKIO distribution traces SHALL be designed for 50 Q. 

RULE B.6.8: 

IF a module accesses the CLKIO signals, 

THEN it SHALL provide 50 Q termination on CLK10+ and CLKIO-, with no more than two (2) equivalent 
ECL loads. 

RULE B.6.9: 

The absolute delay of CLKIO from Slot 0 to any module SHALL NOT exceed 8 ns. 

OBSERVATION B.6.3: 

Either single ended input buffers or differential input buffers can be used to buffer and fan out CLKIO on the 
backplane. Typical components are the lOHlOl and 10H116 buffers. Single ended input buffers may be 
connected to either of the CLK10+ or CLKIO- signals sourced by the module in Slot 0. 
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B.6.2.1.1 LCLKIOO 

LCLKIOO is a 100 MHz system clock. It is sourced from Slot 0 and distributed to Slots 1 -12 on P2. The Slot 0 
output is a low voltage differential signal (LVDS) in compliance with the TIA/EIA-644-A standard. It is 
individually buffered on the backplane and distributed to each module slot via a point-to-point topology (See 
Eigure B.1.1). 

RULE B.6.9.1 

The LCLKIOO signal sourced from Slot 0 SHALL be a 100 MHz LVDS signal as specified in TIA/EIA-644- 
A. Its frequency accuracy SHALL be equal or better than +25 ppm over its specified operating temperature 
and time. 

PERMISSION B.5.3.1: 

The Slot 0 module MAY generate LCLKIOO internally or it MAY derive LCLKIOO from an external source. 

RULE B.6.9.2: 

LCLKIOO duty cycle SHALL be between 45% and 55%. 

RULE B.6.9.3: 

LCLKIOO SHALL be synchronous to CLKIO. The delay from the rising edge of LCLKIOO to either edge of 
CLKIO SHALL meet the timing requirements shown in Ligure X.N 


LCLKIOO 


CLKIO 



Parameter 

Min 

Max 

Description 

T1 

-1 ns 

6.5 ns 

Delay between rising edge of LCLKIOO and rising 
and falling edge of CLKIO 


Figure B.1.1 Relationship between CLKIO and LCLKIOO 


RULE B.6.9.4: 

Each slot’s LCLKIOO SHALL be driven by an independent differential LVDS driver. 

RULE B.6.9.5: 

The LCLKIOO backplane distribution network SHALL NOT insert more than 1 ns timing skew between 
LCLKIOO signals at any two slots. 

RULE B.6.9.6: 

The LCLKIOO and LSYNClOO backplane distribution network SHALL NOT insert more than 1 ns timing 
skew between LCLKIOO and LSYNClOO at any slot. 
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RECOMMENDATION B.6.1.2: 

To minimize the skew, it is recommended to use a single, 1 -to-12 clock distribution buffer on the backplane, 
such as the Micrel SY89113U. 

RULE B.6.9.7: 

The backplane SHALL transmit the LCLKIOO signal to each slot with a transmission line pair having a 
differential impedance of 100 ± 10 fl. 

RULE B.6.9.8: 

The backplane SHALL provide 100 Q differential termination on LCLK100+ and LCLKIOO- signal pair 
sourced from Slot 0. 

RULE B.6.9.9: 

IF a module accesses the LCLKIOO signal, 

THEN it SHALL provide 100 Q differential termination on LCLKlOO-i- and LCLKIOO- signal pair with no 
more than one LVDS receiver (point-to-point topology). 

RULE B.6.9.10: 

IF a module accesses the LCLKIOO signal, 

THEN the on-module LCLKIOO transmission line pair SHALL have a differential impedance of 100 ± 10 

a. 

B.6.2.1.2 LSYNClOO 

The synchronization signal LSYNClOO is used to synchronize multiple devices with respect to a given rising 
edge of LCLKIOO. This provides very tight time coordination between modules. The LSYNClOO signal is 
distributed from Slot 0 to Slots 1-12 on P2 via a point-to-point topology (See Ligure B.l). The relationship of 
LSYNClOO to CLKIO and LCLKIOO allows a VXIbus module to create a local clock that is in phase with the 
CLKIO/LCLKIOO and can be used to synchronize data acquisition, time stamping or trigger generation 
between multiple modules and multiple mainframes. 

A Slot 0 module implementing the LSYNClOO provides an arbiter to synchronize internal and/or external 
events to LCLKIOO and meets the setup and hold times for the LSYNClOO signal. This guarantees that all 
affected modules will be able to synchronize their internal clocks on the same LCLKIOO clock edge. 
LSYNClOO is a nominally 10 ns pulse and may be initiated by any type of external or internal event, such as a 
trigger signal or a software register write. 

RULE B.6.9.11: 

The LSYNClOO signal sourced from Slot 0 SHALL be a LVDS signal as specified in TIA/LIA-644-A (B.6.6 
LVDS Operation). The LSYNC pulse width SHALL be nominally equal to one period of the LCLKIOO signal. 

RULE B.6.9.12: 

Slot 0 modules SHALL provide minimum of 3 ns of setup time from edge of LSYNClOO to the rising edge of 
LCLKIOO. 

RULE B.6.9.13: 

Slot 0 modules SHALL provide minimum of 1 ns of hold time from rising edge of LCLKIOO to the edge of 
LSYNClOO. 
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LCLKIOO 


LSYNClOO 



—H T1 f*— 


Parameter 

Min 

Max 

Description 

T1 

10 ns 


LSYNClOO pulse width (nominal) 

T2 

3 ns 


Minimum LSYNClOO setup time before 

LCLKIOO rising edge 

T3 

1 ns 


Minimum LSYNClOO hold time after LCLKIOO 
rising edge 


Figure B.1.2 LSYNClOO Timing 


RECOMMENDATION B.6.1.3: 

Slot 0 modules which provide LSYNClOO support should be designed such that the LSYNClOO recycle rate is 
50 ns. 

RULE B.6.9.14: 

Lach module slot LSYNClOO SHALL be driven by a unique backplane LVDS buffer output. 

RULE B.6.9.15: 

The LSYNClOO backplane distribution network SHALL NOT insert more than 1.0 ns timing skew between 
LSYNClOO signals at any two slots. 

OBSERVATION B.6.9.16 

LSYNClOO skew matching relative to LCLKIOO is called out under LCLKIOO matching rules. 

RULE B.6.9.17: 

The backplane SHALL transmit the LSYNClOO signal to each slot with a transmission line pair having a 
differential impedance of 100 ± 10 fl. 

RULE B.6.9.18: 

The backplane SHALL provide 100 Q differential termination on LSYNC100+ and LSYNClOO- signal pair 
sourced from Slot 0. 

RULE B.6.9.19: 

IF a module accesses the LSYNClOO signal, 

THEN it SHALL provide 100 Q differential termination on LSYNClOO-i- and LSYNClOO- signal pair with 
no more than one LVDS receiver (point-to-point topology). 

RULE 6.9.20: 

IF a module accesses the LSYNClOO signal, 

THEN the on-module LSYNClOO transmission line pair SHALL have a differential impedance of 100 D ± 10 

a 
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B.6.2.2 MODID LINES 

The MODID lines allow a logical device to be identified with a particular physical location or slot. These lines 
are sourced from the VXIbus Slot 0 module to the Slot 1 and higher modules. There is one line to each 
module, located on P2 pin A30. A total of twelve MODID lines will connect between Slot 0 and the other 
modules in a maximally configured VXIbus subsystem. In addition to these twelve lines, Slot 0 has its own 
MODID line (MODIDOO). The purpose of the MODID lines is to: 

1. Detect the presence of a module in a slot, even if that module has failed. 

2. Identify the geographical location (slot number) of a particular device. 

3. Indicate by lamp or other means the actual physical location of the module. 

Slot 0 detects the presence of a module by the module pulling down its MODID line with a fixed resistor to 
ground. This allows any module, even if failed and un-powered, to be detected. 

The slot number of a device is identified by the Slot 0 module asserting a particular MODID line and polling 
the MODID bit in each module's A16 configuration space to detect the selected device. 

A visual indicator, such as a lamp, may be placed adjacent to a slot (or even on the module) to illuminate when 
that particular MODID line is driven true. This may be used to quickly identify the location of any module, 
including failed modules. Refer to Figure B.l for rules for loading and driving the MODID lines. 

RULE B.6.10: 

Each Slot 0 MODIDxx receiver SHALL comply with the VME64 loading rales for High Current 3 State lines 
(VME64 specification. Rule 6.14). 

RULE B.6.11 

Each Slot 0 MODIDxx driver SHALL comply with the VME64 driving rales for Standard 3 State lines 
(VME64 specification. Rule 6.15). 
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RULE B.6.12: 

Each Slot 0 device SHALL provide a 16.9 kfl pull up resistor from each MODID line to +5 volts. 

RULE B.6.13: 

IF a non-Slot 0 module accesses the MODID pin, 

THEN it SHALL provide an 825 Q pull down to ground in parallel with no more than 100 //A of leakage 
current on its MODID line. 

OBSERVATION B.6.4: 

16.9 kO and 825 Q are standard 1% metal film resistor values. 

RULE B.6.14: 

A VXIbus subsystem backplane SHALL provide an 825 Q pull down to ground on the MODIDOO line. 

RULE B.6.15: 

The backplane SHALL NOT sink or source more than 100 //A of leakage current to any MODID line. 

PERMISSION B.6.1: 

A VXIbus subsystem Slot 0 module MAY drive its MODID line true to illuminate its own module location 
lamp. 
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OBSERVATION B.6.5: 

The proper placement of a Slot 0 module in a Slot 0 position may be verified by a read of its MODIDOO state 
when all Slot 0 MODID drivers are disabled. A low state indicates that the module is in a Slot 0 position. A 
high state indicates that it is in another position. 

B.6.2.3 TTLTRGO-7* (TTL TRIGGER LINES) 

The TTLTRG* lines are open collector TTL lines used for intermodule communication. Any module, 
including Slot 0, may drive these lines and receive information on these lines. They are general purpose lines 
that may be used for trigger, handshake, clock or logic state transmission. They are in a non-asserted (high) 
state until allocated by the user under program control. Some standard allocation procedures are defined. 
Standard protocols, synchronous (SYNC), asynchronous (ASYNC) and start/stop (STST) are defined. To 
compensate for the larger rise time caused by the passive pullup termination, these protocols specify separate 
timing requirements for trigger sources and trigger acceptors. When used for logic state transmission, setup 
and hold times with respect to a clock edge are defined. Other protocols may be defined by a manufacturer. 

OBSERVATION B.6.6: 

The VME64 specification recommends a 100 Q system impedance for open collector lines. Although the 
TTLTRG* lines will be terminated and meet the drive and load requirements for VME64, the characteristic 
impedance of the traces on the backplane may be closer to 50 Q. This allows ECL traces to share the same 
backplane layer and may keep backplanes at manufacturability with the number of planes and thickness for 
component insertion. This should not significantly affect performance of the TTLTRG* lines. 

RULE B.6.16: 

The backplane SHALL terminate all TTLTRG* lines as specified by the VME64 specification, Ligure 6-2, 
Standard Bus Termination. 

RULE B.6.17: 

A module's interface to any TTLTRG* signal line SHALL conform to the driving and loading rules for open 
collector lines (VME64 specification. Section 6.4.2.5). 

RULE B.6.18: 

All TTLTRG* line drivers SHALL be unasserted within one (1) second after SYSRESET* becomes 
unasserted. 

RULE B.6.19: 

A module SHALL allocate any TTLTRG* lines to specific funcfions in groups of 1, 2 or 4. 

RULE B.6.20: 

IF a module uses single line TTLTRG* groups, 

THEN fhaf module SHALL be user-programmable fo conned fo any TTLTRG* line. 

RULE B.6.21: 

IF a module uses fwo line TTLTRG* groups, 

THEN fhaf module SHALL be user programmable to conned all defined TTLTRG* group pairs. The 
defined TTLTRG* group pairs are lines 0 and 1, lines 2 and 3, lines 4 and 5 and lines 6 and 7. 

RULE B.6.22: 

IF a module uses four line TTLTRG* groups, 

THEN fhaf module SHALL be user-programmable to conned to all defined TTLTRG* four line groups. The 
defined TTLTRG* four line group are lines 0, 1, 2 and 3; and lines 4, 5, 6 and 7. 
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B.6.2.3.1 Standard TTLTRG* Protocols 


B.6.2.3.1.1 TTLTRG* SYNCHRONOUS (SYNC) TRIGGER PROTOCOL 

The TTLTRG* SYNC trigger protocol is a single line broadcast trigger that does not require an acknowledge 
from any acceptors. 

RULE B.6.23: 

A TTLTRG* SYNC trigger source SHALL assert the trigger for a minimum time of T1 and SHALL NOT 
reassert the trigger for a minimum time of T2 as shown in Figure B.3. 



Parameter 

Label 

Min 

Max 

Description 

T1 

30 ns 


Minimum source assertion time 

T2 

50 ns 


Minimum source non-assertion time 


Figure B.3. TTLTRG* Synchronous (SYNC) Trigger Protocol 


RULE B.6.24: 

A TTLTRG* SYNC trigger acceptor SHALL accept any trigger asserted for >10 ns, following a >10 ns non¬ 
assertion. 


B.6.2.3.1.2 TTLTRG* ASYNCHRONOUS (ASYNC)TRIGGER PROTOCOL 

The TTLTRG* ASYNC trigger protocol is a two line single source, single acceptor protocol. The source 
initiates an operation by asserting the lower numbered line of the allocated TTLTRG* line pair, while the 
acceptor acknowledges by asserting the higher numbered line of the TTLTRG* line pair. This is a useful 
trigger mode for handshaking between VXIbus modules and external instruments or between VXIbus 
mainframes. 

RULE B.6.25: 

A module implementing the TTLTRG* ASYNC trigger protocol SHALL source only on the lower numbered 
line of a TTLTRG* line pair. 

RULE B.6.26: 

A module implementing the TTLTRG* ASYNC trigger protocol SHALL acknowledge only on the higher 
numbered line of a TTLTRG* line pair. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 




Page 30 


Section B: VXIbus Implementation of VMEbus Specs 


RULE B.6.27: 

IF a module implements the TTLTRG* ASYNC trigger protocol 
THEN it SHALL meet the timing requirements shown in Figure B.4. 



Parameter 

Label 

Min 

Max 

Description 

T1 

30 ns 


Minimum Source assertion time 

T2 

0 ns 


Minimum Acceptor response time 

T3 

30 ns 


Minimum Acceptor assertion time 

T4 

50 ns 


Minimum Source non-assertion time 

T5 

0 ns 


Minimum Acceptor Acknowledge to source re-assertion time 


Figure B.4. TTLTRG* Asynchronous (ASYNC) Trigger Protocol 


RULE B.6.28: 

A TTLTRG* ASYNC trigger source or acceptor SHALL accept any trigger asserted for >10 ns following a 
>10 ns unassertion. 


B.6.2.3.1.3 TTLTRG* CLOCK TRANSMISSION 

A TTLTRG* line may be used for a clock signal transmission. 

RULE B.6.29: 

IF A TTLTRG* line is used for clock transmission, 

THEN it SHALL meet the timing requirements described for the TTLTRG* SYNC trigger protocol. 
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OBSERVATION B.6.7: 

In a fully loaded VXIbus subsystem, the TTLTRG* rise time will approach 40 nanoseconds. For this reason, 
the falling edge is used for triggering. 


B.6.2.3.1.4 TTLTRG* DATA TRANSMISSION 

The TTLTRG* lines can also be used for data transmission, where one of the TTLTRG* lines is used as a 
clock. Data may be synchronized to either the rising or falling edge of the clock or both. 

RULE B.6.30: 

IF a source uses TTLTRG* lines for data transmission on a falling clock edge, 

THEN the source SHALL meet the timing requirements shown in Figure B.5. 



Parameter Label 

Min 

Max 

Description 

T1 

40 ns 


Data setup time 

T2 

10 ns 


Data hold time 


Figure B.5. TTLTRG* Data Transmission on falling clock edge 


RULE B.6.31: 

IF a source uses TTLTRG* lines for data transmission on a rising clock edge, 

THEN the source SHALL meet the timing requirements shown in Figure B.6. 

RULE B.6.32: 

A TTLTRG* data acceptor SHALL accept any data having data setup and hold times of >7 ns each. 
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2.0 V- 
0.8 V- 


Trigger or Clock 



0.8 V- 




T1 


2.0 V- 
0.8 V- 



T2 


Parameter 

Label 

Min 

Max 

Description 

T1 

T2 

40 ns 
40 ns 


Data setup time 
Data hold time 


Figure B.6. TTLTRG* Data Transmission on rising clock edge 


B.6.2.3.1.5 START/STOP (STST) PROTOCOL 

The Start/Stop protocol (STST) provides a method for starting and stopping module clusters synchronously. 
One TTLTRG* line is driven from the Slot 0 module and its state signifies START or STOP operation. All 
participating modules respond to this line synchronously at the next CLKIO rising edge. Slot 0 has the 
responsibility to synchronize the START/STOP signal with CLKIO so that setup and hold times are guaranteed 
for all acceptors. This may require an arbiter in Slot 0 to synchronize external events. 

RULE B.6.33: 

IF a module implements STST protocol, 

THEN the START/STOP line SHALL be user-programmable to connect to any TTLTRG* line. 

RULE B.6.34: 

IF a Slot 0 module implements the STST protocol, 

THEN it SHALL meet the timing requirements shown in Figure B.7. 

RULE B.6.35: 

A TTLTRG* STST acceptor SHALL accept any STST command having data setup and hold times of >7 ns 
each. 

RULE B.6.36: 

When implementing the STST protocol, START SHALL be represented by a low (asserted) state on the 
START/STOP TTLTRG* line and STOP SHALL be represented by a high (unasserted) state on the 
START/STOP TTLTRG* line. 
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Parameter 

Label 

Min 

Max 

Description 

T1 

50 ns 


START/STOP setup time 

T2 

15 ns 


START/STOP hold time 


Figure B.7. TTLTRG* START/STOP timing 


B.6.2.3.1.6 EXTERNAL TRIGGER BUEEERING 

OBSERVATION B.6.8: 

The TTLTRG* loading and driving rules require that these lines be buffered when extended outside a 
mainframe. 

RECOMMENDATION B.6.2: 

When extending a trigger operation external to a VXIbus chassis, the buffer module should source and accept 
signals as described in the Standard External Trigger Buffer below. 

B.6.2.3.1.6.1 Standard External Trigger Buffer 

To maximize the compatibility between multiple VXIbus mainframes or a VXIbus mainframe and external 
instruments, a standard buffering scheme for TTLTRG* lines is recommended. A source has an output series 
impedance of 50 Q. Its open circuit low level output is <0.4 V and its open circuit high level output is >4.2 V. 
50 Q cable is recommended for connection from the source module to other VXIbus mainframes or 
instruments. Eor highest performance, terminate the cable with 50 Q at the furthest point from the source. The 
acceptor's threshold level is centered at 1.5 V with a loading impedance of >5 kG. The TTLTRG* sense 
remains non-inverted (Asserted state is low). See Ligure B.8. 

OBSERVATION B.6.9: 

The Standard External Trigger Buffer requires only simple buffering to implement the SYNC and ASYNC 
trigger protocols. 
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B.6.2.4 ECLTRGO-1 (ECL TRIGGER LINES) 

The ECLTRG lines are intended to be an intermodule timing resource. These two lines are bussed the length 
of the VXIbus subsystem backplane. Any module, including the Slot 0 module, may drive these lines and 
receive information from these lines. These lines are single-ended ECL and have a system impedance of 50 Q. 
The asserted state is defined as logical high. Eigure B.9 shows a typical ECL interface. 

RULE B.6.37: 

Each ECLTRG line SHALL be terminated with 50 Q to -2 V at each end of the backplane. This requires that 
any driver be able to drive 25 Q. 

RULE B.6.38: 

The maximum ECLTRG trace length from the P2 DIN connector pad on any module SHALL NOT exceed 
1.0 inch. 

RECOMMENDATION B.6.3: 

The transmission line impedance connecting the P2 DIN connector to the ECLTRG receiver/driver circuitry 
should be 50 Q. 

RECOMMENDATION B.6.4: 

A module that senses the ECLTRG lines should have a 150 Q resistor in series with the transmission line 
connecting the ECL trigger lines on the P2 DIN connector to the line receiver. 

RULE B.6.39: 

Each module SHALL NOT have more than one equivalent driver/receiver load on any ECLTRG line. 
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RULE B.6.40: 

IF a module drives the ECLTRG bus, 

THEN it SHALL use ECL drivers which provide a LOW output level which is less (more negative) than the 
-2 V termination supply, e.g. 10H123. 

OBSERVATION B.6.10: 

Using drivers which produce a high impedance LOW level for ECLTRG lines eliminates the glitching which 
occurs when ECL devices are WIRE-OR'ed. 

RULE B.6.41: 

IF a module connects to an ECLTRG line 

THEN it SHALL unassert that within one (1) second after SYSRESET* becomes unasserted. 

RULE B.6.42: 

ECLTRG lines SHALL be allocated in groups of 1 or 2 and meet the same allocation rules as defined for the 
TTLTRG* lines. 


ECLTRGn 



Figure B.9. Typical ECLTRG Interface 


B.6.2.4.1 Standard ECLTRG Protocols 

The ECLTRG lines have a set of defined protocols corresponding to the TTLTRG* protocols. These protocols 
are defined in the following sections. 


B.6.2.4.1.1 ECLTRG SYNCHRONOUS (SYNC) TRIGGER PROTOCOL. 

The ECLTRG SYNC trigger protocol is a single line broadcast trigger that does not require an acknowledge 
from any acceptors. 
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RULE B.6.43: 

An ECLTRG SYNC trigger source SHALL assert the trigger for a minimum time of T1 and SHALL NOT 
reassert the trigger for a minimum time of T2 as shown in Eigure B.IO. 

RULE B.6.44: 

An ECLTRG SYNC trigger acceptor SHALL accept any trigger asserted for >6 ns following a >6 ns non¬ 
assertion. 



Parameter 

Label 

Min 

Max 

Description 

T1 

8 ns 


Minimum source assertion time 

T2 

8 ns 


Minimum source non-assertion time 


Figure B.IO. ECLTRG Synchronous (SYNC) Trigger Protocol 


B.6.2.4.1.2 ECLTRG ASYNCHRONOUS (ASYNC) TRIGGER PROTOCOL 

The ECLTRG ASYNC trigger protocol is a two line single source, single acceptor protocol. The source 
initiates an operation by asserting the lower numbered line of the allocated ECLTRG line pair, while the 
acceptor acknowledges by asserting the higher numbered line of the ECLTRG line pair. This is a useful trigger 
mode for handshaking between VXIbus modules and external instruments. 

RULE B.6.45: 

A module implementing the ECLTRG ASYNC trigger protocol SHALL source only on the lower numbered 
line of an ECLTRG line pair. 

RULE B.6.46: 

A module implementing the ECLTRG ASYNC trigger protocol SHALL acknowledge only on the higher 
numbered line of an ECLTRG line pair. 

RULE B.6.47: 

IF a module implements the ECLTRG ASYNC trigger protocol 
THEN it SHALL meet the timing requirements shown in Eigure B.l 1. 

RULE B.6.48: 

An ECLTRG ASYNC trigger source or acceptor SHALL accept any trigger asserted for >6 ns following a 
>6 ns non-assertion. 
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B.6.2.4.1.3 ECLTRG CLOCK TRANSMISSION 

An ECLTRG line may be used for a clock signal transmission. 

RULE B.6.49: 

IF An ECLTRG line is used for clock transmission, 

THEN it SHALL meet the timing requirements described for the ECLTRG SYNC trigger protocol. 



Parameter 

Label 

Min 

Max 

Description 

T1 

8 ns 


Minimum Source assertion time 

T2 

0 ns 


Minimum Acceptor response time 

T3 

8 ns 


Minimum Acceptor assertion time 

T4 

8 ns 


Minimum Source non-assertion time 

T5 

0 ns 


Minimum Acceptor Acknowledge to source re-assertion time 


Figure B.ll. ECLTRG Asynchronous (ASYNC) Trigger Protocol 


B.6.2.4.1.4 ECLTRG DATA TRANSMISSION 

The ECLTRG lines can also be used for data transmission, where one of the ECLTRG lines is used as a clock. 
Data may be synchronized to either the rising or falling edge of the clock or both. 

RULE B.6.50: 

IF a source uses ECLTRG lines for data transmission, 

THEN the source SHALL meet the timing requirements shown in Eigure B.12. 

RULE B.6.51: 

An ECLTRG data acceptor SHALL accept any data with a setup time of >6 ns and a hold time of >2 ns. 
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Parameter 

Labels 

Min 

Max 

Description 

T1 

8 ns 


Data setup time 

T2 

4 ns 


Data hold time 


Figure B.12. ECLTRG Data Transmission 


B.6.2.4.1.5 EXTENDED START/STOP (ESTST) PROTOCOL 

Extended START/STOP (ESTST) protocol is the natural extension of the START/STOP (STST) protocol to 
D-size modules. Because the modules may contain P3 and utilize CLKIOO as their instrument clock, three 
additional signals have been added to the STST protocol (CLKIOO, SYNClOO and an ECLTRG line). The 
ECLTRG line determines whether an ESTST operation is initiated, while the same TTLTRG line used to 
transmit the START/STOP value for STST devices also determines the START or STOP operation for ESTST 
devices. 

In the ESTST protocol, a Slot 0 SYNClOO driver (See Sec. B.6.3.2, "SYNClOO") selects a particular CLKIOO 
clock edge to initiate the START or STOP command. An ECLTRG line indicates whether the SYNClOO pulse 
is related to the ESTST protocol. This line is known as the ESTST qualifier line. Since the CLKIO and 
CLKIOO signals are synchronized, the Slot 0 module can always qualify a CLKIOO edge having a fixed phase 
relationship to CLKIO. This fixed phase relationship, over a series of ESTST operations, guarantees fixed and 
repeatable delays between modules paced by CLKIO (STST) and those paced by CLKIOO (ESTST). The 
TTLTRG* line used to indicate START/STOP for the STST protocol also determines START or STOP for the 
ESTST protocol. 

RULE B.6.52: 

IF a module implements the ESTST protocol, 

THEN the module SHALL be user programmable to select any ECLTRG line as the ESTST qualifier line. 

RULE B.6.53: 

ESTST qualifier true SHALL be represented by a high state of the selected ECLTRG ESTST qualifier line and 
ESTST qualifier false SHALL be represented by a low state. 
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RULE B.6.54: 

A Slot 0 module implementing the ESTST protocol SHALL meet the timing requirements of Eigure B.13. 

RULE B.6.55: 

A Slot 0 module implementing the ESTST protocol SHALL meet the timing requirements for the STST 
protocol. 

RULE B.6.56: 

An ESTST acceptor SHALL accept a SYNClOO setup value for >2 ns and held for >0.5 ns, an ESTST 
qualifier value setup for >4 ns and held for >2 ns and a STST value setup >7 ns and held for >7 ns with respect 
to the CLKIOO edge. 


B.6.2.4.1.6 EXTERNAL TRIGGER BUEEERING 

RECOMMENDATION B.6.5: 

Since the ECLTRG asserted sense is opposite the TTLTRG* asserted sense, the ECLTRG signal should be 
inverted by the Standard External Trigger Buffer. This allows compatibility of external ECLTRG and 
TLTRG* signals. 

OBSERVATION B.6.11: 

By meeting the loading and driving rules for ECLTRG lines, a module is prohibited from extending these lines 
external to the chassis without buffering these lines. See Section B.6.2.3.1.6.1, "Standard External Trigger 
Buffer." 


B.6.2.5 SUMBUS 

The SUMBUS is an analog summing node that is bussed the length of the VXIbus subsystem backplane. It is 
intended that any module be able to drive or receive from this line. Each module can drive this line using an 
analog current source driver. Each module may receive information from this bus through a high impedance 
receiver, such as a high impedance analog buffer amplifier. 

RULE B.6.57: 

The SUMBUS SHALL be ferminafed to signal ground fhrough 50 + 1 Q af each end of fhe backplane. 

RULE B.6.58: 

A receiver on fhe SUMBUS SHALL have an equivalenf inpuf impedance of >10 kG in parallel wifh <3 pE. 

RULE B.6.59: 

A SUMBUS oufpul currenf source SHALL have an equivalenf oufpuf impedance of >10 kQ in parallel wifh 
<4 pE. 

RULE B.6.60: 

A SUMBUS oufpul currenf source SHALL have +0.8 V minimum compliance. 

RULE B.6.61: 

A SUMBUS oufpul currenf source SHALL NOT source more lhan 40 mA. 

RULE B.6.62: 

The backplane SHALL supply a SUMBUS proleclion nelwork lhal clamps fhe SUMBUS vollage wilhin fhe 
range +3.0 V for all SUMBUS inpul currenls in fhe range of +520 mA. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 



Page 40 


Section B: VXIbus Implementation of VMEbus Specs 



Parameter 

Label 

Min 

Max 

Description 

T1 

4.0 ns 

7.5 ns 

SYNClOO setup time 

T2 

3.5 ns 

6.0 ns 

SYNClOO hold time 

T3 

13.0 ns 


ESSTST Qualifier setup time 

T4 

11.0 ns 


ESTST Qualifier hold time 

T5 

50.0 ns 


START/STOP setup time 

T6 

15.0 ns 


START/STOP hold time 


Figure B.13. CLKIOO, SYNClOO and ECLTRG START/STOP Timing 


RULE B.6.63: 

The SUMBUS protection network SHALL NOT source or sink more than +1.0 //A nor load with greater than 
30 pE for SUMBUS voltages in the range +1.0 V. 

OBSERVATION B.6.12: 

Low leakage diodes may be required to meet the SUMBUS leakage requirement. 

SUGGESTION B.6.1: 

Because all modules may drive the SUMBUS at the same time, a module designer should consider the total 
dynamic range of a SUMBUS output current source and be able to adjust the maximum output current 
accordingly. This will keep the signal within the compliance region. 
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RULE B.6.64: 

SUMBUS output current sources and receivers SHALL NOT be located more than 1.0 inch from the P2 DIN 
SUMBUS pad. 

RULE B.6.65: 

When a module's SUMBUS module output current source is disabled, the module SHALL NOT source more 
than +1.0 /lA into the SUMBUS. 

B.6.2.6 LOCAL BUS 

The Local Bus is a daisy chained bus consisting of 20 lines. It is defined by adjacently installed modules. The 
backplane connects from the LBUSC pins of Slot N to the LBUSA pins of Slot N+1. See Figure B.l. No 
Local Bus lines are extended beyond Slot 12. Several classes of signal levels are allowed and may be 
transmitted via this bus. To ensure that modules which produce incompatible levels are not installed in 
adjacent slots, a keying mechanism has been provided. The Local Bus key provides support for TTL, ECL and 
analog communication. Each module indicates with the mechanical key on the faceplate which classes of 
signals it may source or accept nondestructively on each side of its Local Bus. The particular key position for 
each of the signal classes, as well as sensor-only devices, are specified in the Mechanical Specifications 
(Section B.7). Sensor-only devices are modules that can non-destructively accept signals of a number of 
classes, but do not source any signals of their own. Lockout keys are provided to serve as an impediment to 
local bus incompatibilities between modules. Refer to Figure B.28. 


NUMBER 

CLASS 

-LIMIT 

+LIMIT 

DRIVE LIMIT 

1 

TTL 

-0.5 V 

+5.5 V 

200 mA 

2 

ECL 

-5.46 V 

0.0 V 

50 mA 

3 

ANALOG LOW 

-5.5 V 

+5.5 V 

50 Q Drive 

4 

ANALOG MED 

-16.0 V 

+16.0 V 

500 mA 

5 

6 

ANALOG HIGH 
RESERVED 

-42.0 V 

+42.0 V 

500 mA 


TABLE B.3. Logical Classes of LBUS Signals 


RULE B.6.66: 

Modules SHALL NOT drive more than +42 V onto any LBUS line. 

RULE B.6.67: 

Modules SHALL NOT drive more than 500 mA DC current into any LBUS line. 

RULE B.6.68: 

The backplane resistance between any LBUS line and any adjacent pin SHALL be greater than 10.0 MQ 

RULE B.6.69: 

The di/dt on any LBUS line SHALL NOT exceed +100 mA/ns. 

RECOMMENDATION B.6.6: 

Multi-Module instrument systems which utilize the Local Bus for intra-system communications should be built 
with anchor and expander protocol. An anchor module has no connections on LBUSA lines. It may drive or 
receive LBUSC lines. An expander module may drive or receive LBUSA or LBUSC lines. Expanders 
should be placed in adjacent slots (of higher number) to the anchor. This protocol always guarantees 
compatibility between adjacent module groups without empty slots. 

RULE B.6.70: 

Any module that accesses the LBUS lines SHALL indicate its class on its local bus keys. 

RULE B.6.71: 
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A module SHALL NOT exceed the voltage specified for its class under any loading conditions. 

OBSERVATION B.6.13: 

If a module provides a direct connection (an electrical short) between LBUSA lines and LBUSC lines, the 
keying mechanism should indicate that the module will source on LBUSA and LBUSC any class it accepts on 
either LBUSA or LBUSC respectively. 

RULE B.6.72: 

A module SHALL NOT indicate on its key the RLSLRVLD signal class. 

OBSERVATION B.6.14: 

The keying mechanism cannot prevent a destructive condition in all situations. It is good practice for a module 
manufacturer to protect his modules from destruction by any signals within the class it accepts. 

RULE B.6.73: 

The Slot 0 P2 LBUSA key SHALL indicate TTL class. 

RULE B.6.74: 

The Slot 0 P3 LBUSA and LBUSC keys SHALL indicate ECL class. 

RULE B.6.75: 

The mainframe (if it supports VXIbus Subsystem P2) SHALL provide a Slot 0 P2 LBUSC key which indicates 
TTL class. 

RULE B.6.76: 

The mainframe (if it supports VXIbus Subsystem P3) SHALL provide a Slot 0 P3 LBUSC key which indicates 
ECL class. 

PERMISSION B.6.2: 

A device which non-destractively senses signals up to +16 volts, but does not source any signals or provide 
direct connection between LBUSA and LBUSC, MAY provide a single local bus key tab for +16 V sensor- 
only operation. 

PERMISSION B.6.3: 

A device which non-destructively senses all classes of signals up to +42 volts, but does not source any signals 
or provide direct connection between LBUSA and LBUSC, MAY provide no local bus key tabs for +42 V 
sensor-only operation. Such a device cannot cause a destructive condition. 

OBSERVATION B.6.15: 

A device that does not access the local bus does not provide any local bus keys. 

OBSERVATION B.6.16: 

Size A, B and C modules do not provide P3 local bus keys. 

B.6.2.7 RSV2-3 (RESERVED) 

These pins are reserved. 

RULE B.6.77: 

Modules and backplanes SHALL NOT make any connections to RSV pins. 

B.6.2.8 Control of Backplane and Mainframe Resources 

The pins SDAO/SCLO, SDAl/SCLl, found on the P2 connector of Slot 0, implement two I^C busses to allow 
control/monitoring of backplane and mainframe resources. This will greatly reduce the efforts for designers of 
such resources as mainframe monitoring devices, since it removed the need for implementing a full VXIbus 
slave interface. 
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2 

All I C-bus compatible devices incorporate an on-chip interface which allows them to communicate directly 
with each other via the I^C-bus. Two wires, serial data (SDA) and serial clock (SCL), carry information 
between the devices connected to the bus. Each device connected to the bus is software addressable by a 
unique address and simple master/slave relationships that exist at all times. On-chip filtering is designed for 
high noise immunity on the data bus line to preserve data integrity. The maximum number of devices is 
limited only by the maximum bus capacitance of 400pE. Refer to the I^C-bus Specification, Version 2.1, 
January 200 for more specific informafion. 

B.6.2.9 Star Trigger Lines 

The Sfar Trigger lines STRGylN-h/STRGylN- (y = 0-2) and STRGOUTxx-i-/STRIGOUTxx- (xx = 01-12) are 
used fo implemenf a low skew, low jiffer frigger mefhod for precise simulfaneous sysfem wide friggering/ 
sampling. Sfar frigger disfribufion logic in fhe slof 0 confroller allows for one-lo-one and one-fo-many frigger 
disfribufion among all slofs wifh very low skew (around 0.5ns fypical). The disfribufion logic is confrolled by 
fhe Slof 0 confroller. Modules in slofs 1-12 fhaf supporf Sfar Trigger shall be able fo source one differenlial 
LVDS frigger fo fhe Slof 0 Sfar Trigger disfribufion logic. The Slof 0 Sfar Trigger disfribufion logic is 
programmed fo route any of fhese Sfar Trigger inpufs fo any of fhe fhree sfar frigger oufpufs. The sfar frigger 
oufpufs from fhe disfribufion logic are roufed fo fhe slof 1-12 Sfar Trigger inpuf lines. The Sfar Trigger in and 
Sfar Trigger oul signal lines use low-volfage differenlial signaling and musl be lenglh-malched on fhe 
backplane and in fhe slof 0 confroller. The propagalion delay should malched in fhe disfribufion logic and 
drivers. See Eigure 13.1. 



Figure B.13.1 Sfar Trigger Signal Routing 


RULE B.6.77.1: 

The Sfar Trigger line backplane SHALL NOT inserl more lhan 0.25 ns timing skew belween any Iwo 
STRGOUTxx and STRGyIN poinls. The slof 0 Sfar Trigger palhs and disfribufion logic SHALL NOT inserl 
more lhan 0.5 ns timing skew round Irip belween any routed Sfar Trigger palhs. 
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OBSERVATION B.6.16.1: 

Total propagation delay equals the total delay introduced by the backplane tracks, slot 0 tracks, and distribution 
logic between the STRGOUTxx and STRIGyIN of one connector to the other. Total skew is the total variation 
in time between edges arriving at any backplane connector from any other star trigger connector. 

OBSERVATION B.6.16.2: 

If total delay and skew for the system (backplane, slot 0 and module) are to be specified, then module delay 
and skew need to be specified as well as backplane track length and slot 0 track length and propagation delay. 
This is further illustrated in the figure below. See Figure 13.2. 


On the module, if absolute skew needs to be 
bounded, then if the length from BP to RX/TX 
is fixed ± x%, and length fro RX/TX to 
module logic is fixed ± y%. Total trigger skew 
can be determined. 

Equal length runs from each module to and from the slot 0 
controller. Assume worst case track length = Rack Width *1.25. 
(17x 1.25) = 23.75 in. 

Propagation speed (min) in FR4 = 180 ps/in. 
Propagation delay (max) = 180 ps/in. * 23.75 in. = 4.2714 ns 
LVDS driver delay (max) = 5 ns with 70 ps skew 

Assume tracks are matched to 0.7 in., max skew = 125 ps 

Specify the worst case propagation delay 
through the distribution logic = 5.725 ns. 
Track length (max) = V 2 Module Depth * 1.25 
Prop, delay (max) = 180 ps * 6.69" = 1.2 ns 
Total PD (max) = 5.725 ns + 1.2 ns = 6.925 ns 
Assume matched tracks to 0.7", max skew = 125 ps 
Typical LVDS chip channel-channel skew = 125 ps 
Typical total skew * 250 ps 

STRG_OUT_x 

STRG_IN_x 

Max total skew « 195 ps 


Two way prop delay = 2 * 4.2714 ns + 5 ns = 13.5428 ns 

Slot 0 Controller 

Internal Paths and 

Distribution Logic 



Users can be required to list total skew on start 

-Total propagation delay through Star Trigger Logic (max) = 13.5428 ns + 6.925 ns = 20.4678 ns -^ 

trigger just as they are required to list power 

Total skew from backplane and Slot 0 = 445 ps 

and cooling, etc. 

Chassis and slot 0 specify min / typical / max propagation delay for star trigger 


Figure B.13.2 Sfar Trigger Signal Performance 


RULE B.6.77.2: 

Sfar Trigger lines SHALL be driven by an independent differential LVDS driver. 

RULE B.6.77.3: 

Star Trigger line distribution traces on the backplane, in the slot 0 controller, and on the VXI 4.0 modules 
SHALL have a differential impedance of 100 G ± 10 G. 

RULE B.6.77.4: 

The backplane Star Trigger line distribution drivers and traces SHALL NOT insert more than 9 ns propagation 
delay round trip to and from the slot 0 for any given trigger routing. The slot 0 SHALL NOT insert more than 
7 ns propagation delay for any given trigger routing. 

RULE B.6.77.5: 

The propagation delay inserted by the backplane Star Trigger lines and by the slot 0 distribution mechanism 
SHALL be published by the backplane and slot 0 manufacturers, respectively. 

RULE B.6.77.6: 

IF a module accesses the Star Trigger signals 

THEN it SHALL provide 100 Q differential termination with no more than one LVDS receiver (point-to-point 
topology). 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 





















Section B: VXIbus Implementation of VMEbus Specs 


Page 45 


B.6.3 The VXIbus Subsystem P3 Connector 

For higher performance instrumentation, the VXIbus also defines the P3 connector. As with P2, alternate pin 
definitions of P3 may coexist in VXIbus systems, but any one VXIbus subsystem must exist in contiguous 
slots. Again, Slot 0 plays a unique role in delivering system resources on P3, such as high speed clocking and 
trigger routing. In particular, VXIbus P3 adds: 

Additional +5 V, -5.2 V, -2 V, +24 V and +12 V power. 

100 MHz differential clock which is synchronous with the P2 10 MHz clock. 

A synchronizing signal for 100 MHz clock edge selection. 

4 additional ECL trigger lines, for a total of 6. 

24 additional local bus lines, for a total of 36. 

"Star Trigger" lines for precision module to module timing. 


B.6.3.1 CLKIOO 

CLKIOO is a 100 MHz system clock. It is sourced from Slot 0 and distributed to slots 1 -12 on P3. The Slot 0 
CLKIOO output is differential ECL. It is buffered on the backplane and distributed to each module slot as a 
single source, single destination differential ECL signal in a manner similar to CLKIO. The distribution delays 
are matched to provide a tight timing relationship between modules. The backplane buffering provides a high 
level of inter-module isolation. 

RULE B.6.78: 

The CLKIOO frequency sourced from Slot 0 SHALL be 100 MHz. Its accuracy SHALL be equal to or better 
than +100 ppm (0.01%), over its specified operating temperature and time. 

OBSERVATION B.6.17: 

A Slot 0 module may generate CLKIOO internally or it may derive CLKIOO from an external frequency source. 

RULE B.6.79: 

CLKIOO duty cycle SHALL be 50% +20% when measured at the 50% transition level. 

RULE B.6.80: 

IF CLKIOO is switched between different clock sources, 

THEN the minimum clock width, high or low, SHALL NOT be less than 2.5 ns or more than 1.0 ms during 
switching. The minimum time between two successive transitions of the same polarity SHALL NOT be less 
than 9.5 ns. 

RULE B.6.81: 

CLKIOO SHALL be synchronous to CLKIO. 

OBSERVATION B.6.18: 

The absolute timing relationship between CLKIO and CLKIOO is not specified. This relationship may be 
produced by deriving CLKIO from CLKIOO or deriving CLKIOO from CLKIO. 
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PIN 

ROW ‘z’ 

ROW ‘a’ 

ROW ‘b’ 

ROW ‘c’ 

ROW ‘d’ 

NUMBER 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 


MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

1 

RsrvBus 

ECLTRG2 

+24V 

-i12V 

RsrvBus 

2 

GND 

GND 

-24V 

-12V 

RsrvBus 

3 

RsrvBus 

ECLTRG3 

GND 

RSV4 

RsrvBus 

4 

GND 

-2V 

RSV5 

-i5V 

RsrvBus 

5 

RsrvBus 

ECLTRG4 

-5.2V 

RSV6 

RsrvBus 

6 

GND 

GND 

RSV7 

GND 

RsrvBus 

7 

RsrvBus 

ECLTRG5 

-i5V 

-5.2V 

RsrvBus 

8 

GND 

-2V 

GND 

GND 

RsrvBus 

9 

RsrvBus 

LBUSA12 

-i5V 

LBUSC12 

RsrvBus 

10 

GND 

LBUSA13 

LBUSC15 

LBUSC13 

RsrvBus 

11 

RsrvBus 

LBUSA14 

LBUSA15 

LBUSC14 

RsrvBus 

12 

GND 

LBUSA16 

GND 

LBUSC16 

RsrvBus 

13 

RsrvBus 

LBUSA17 

LBUSC19 

LBUSC17 

RsrvBus 

14 

GND 

LBUSA18 

LBUSA19 

LBUSC18 

RsrvBus 

15 

RsrvBus 

LBUSA20 

-i5V 

LBUSC20 

RsrvBus 

16 

GND 

LBUSA21 

LBUSC23 

LBUSC21 

RsrvBus 

17 

RsrvBus 

LBUSA22 

LBUSA23 

LBUSC22 

RsrvBus 

18 

GND 

LBUSA24 

-2V 

LBUSC24 

RsrvBus 

19 

RsrvBus 

LBUSA25 

LBUSC27 

LBUSC25 

RsrvBus 

20 

GND 

LBUSA26 

LBUSA27 

LBUSC26 

RsrvBus 

21 

RsrvBus 

LBUSA28 

GND 

LBUSC28 

RsrvBus 

22 

GND 

LBUSA29 

LBUSC31 

LBUSC29 

RsrvBus 

23 

RsrvBus 

LBUSA30 

LBUSA31 

LBUSC30 

RsrvBus 

24 

GND 

LBUSA32 

-i5V 

LBUSC32 

RsrvBus 

25 

RsrvBus 

LBUSA33 

LBUSC35 

LBUSC33 

RsrvBus 

26 

GND 

LBUSA34 

LBUSA35 

LBUSC34 

RsrvBus 

27 

RsrvBus 

GND 

GND 

GND 

RsrvBus 

28 

GND 

STARY+ 

-5.2V 

STARY+ 

RsrvBus 

29 

RsrvBus 

STARY- 

GND 

STARY+ 

RsrvBus 

30 

GND 

GND 

-5.2V 

-5.2V 

RsrvBus 

31 

RsrvBus 

CLK100+ 

-2V 

SYNC100+ 

RsrvBus 

32 

GND 

CLK100- 

GND 

SYNC100- 

RsrvBus 


TABLE B.4. P3 Pin Definitions 
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PIN 

ROW ‘z’ 

ROW ‘a’ 

ROW ‘b’ 

ROW ‘c’ 

ROW ‘d’ 

NUMBER 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 


MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

1 

RsrvBus 

ECLTRG2 

+24V 

-i12V 

RsrvBus 

2 

GND 

GND 

-24V 

-12V 

RsrvBus 

3 

RsrvBus 

ECLTRG3 

GND 

RSV4 

RsrvBus 

4 

GND 

-2V 

RSV5 

-i5V 

RsrvBus 

5 

RsrvBus 

ECLTRG4 

-5.2V 

RSV6 

RsrvBus 

6 

GND 

GND 

RSV7 

GND 

RsrvBus 

7 

RsrvBus 

ECLTRG5 

-i5V 

-5.2V 

RsrvBus 

8 

GND 

-2V 

GND 

GND 

RsrvBus 

9 

RsrvBus 

STARX12+ 

-i5V 

STARX01+ 

RsrvBus 

10 

GND 

STARX12- 

STARY01 - 

STARX01- 

RsrvBus 

11 

RsrvBus 

STARY12+ 

STARY12- 

STARYOU 

RsrvBus 

12 

GND 

STARX11+ 

GND 

STARX02+ 

RsrvBus 

13 

RsrvBus 

STARX11- 

STARY02- 

STARX02- 

RsrvBus 

14 

GND 

STARY11+ 

STARY11 - 

STARY02-I- 

RsrvBus 

15 

RsrvBus 

STARX10+ 

-i5V 

STARX03+ 

RsrvBus 

16 

GND 

STARX10- 

STARY03- 

STARX03- 

RsrvBus 

17 

RsrvBus 

STARY10+ 

STARY10- 

STARY03-I- 

RsrvBus 

18 

GND 

STARX09+ 

-2V 

STARX04+ 

RsrvBus 

19 

RsrvBus 

STARX09- 

STARY04- 

STARX04- 

RsrvBus 

20 

GND 

STARY09+ 

STARY09- 

STARY04-I- 

RsrvBus 

21 

RsrvBus 

STARX08+ 

GND 

STARX05+ 

RsrvBus 

22 

GND 

STARX08- 

STARY05- 

STARX05- 

RsrvBus 

23 

RsrvBus 

STARY08+ 

STARY08- 

STARY05-I- 

RsrvBus 

24 

GND 

STARX07+ 

-i5V 

STARX06+ 

RsrvBus 

25 

RsrvBus 

STARX07- 

STARY06- 

STARX06- 

RsrvBus 

26 

GND 

STARY07+ 

STARY07- 

STARY06-I- 

RsrvBus 

27 

RsrvBus 

GND 

GND 

GND 

RsrvBus 

28 

GND 

STARY+ 

-5.2V 

STARX+ 

RsrvBus 

29 

RsrvBus 

STARY- 

GND 

STARX- 

RsrvBus 

30 

GND 

GND 

-5.2V 

-5.2V 

RsrvBus 

31 

RsrvBus 

CLK100+ 

-2V 

SYNC100+ 

RsrvBus 

32 

GND 

CLK100- 

GND 

SYNC100- 

RsrvBus 


TABLE B.5. P3 Slot 0 Pin Definitions 
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RULE B.6.82: 

The CLKIOO and SYNC 100 backplane distribution network SHALL NOT insert more than 2.0 ns timing 
skew between CLKIOO and SYNClOO at any slot. 

OBSERVATION B.6.19: 

If a lOHlOl distribution buffer is used for CLKIOO or SYNClOO, the trace lengths should be matched within 
1 ns (approximately 15 cm (6 inches)). 

RULE B.6.83: 

Lach slot's CLKIOO SHALL be differentially driven by a unique backplane buffer output. 

RULE B.6.84: 

CLKIOO SHALL be differentially driven onto the CLK100+ and CLKIOO- pins by the module in Slot 0. 

RULE B.6.85: 

The backplane CLKIOO distribution traces SHALL be designed for 50 Q 

RULE B.6.86: 

The CLKIOO backplane distribution network SHALL NOT insert more than 2.0 ns timing skew between 
CLKIOO signals at any two slots. 

RULE B.6.87: 

The absolute delay of CLKIOO from Slot 0 to any module SHALL NOT exceed 8 ns. 

RULE B.6.88: 

IF a module accesses the CLKIOO signals 

THEN it SHALL provide 50 Q termination on CLKlOO-i- and CLKIOO-, with no more than two equivalent 
LCL loads. 


B.6.3.2 SYNClOO 

The synchronization signal SYNClOO, is used to synchronize multiple devices with respect to a given rising 
edge of CLKIOO. This provides very tight time coordination between modules. The SYNClOO signal is 
distributed from Slot 0 to slots 1-12, with individual backplane buffers for each slot. The SYNClOO signal can 
be compared to the GPIB Group Execute Trigger command in function, but with greatly improved time 
coordination. As the Slot 0 module drives the SYNClOO and CLKIOO signals, it may also be programmed to 
drive one or more ECLTRG lines in order to qualify the SYNClOO action. An example of this protocol is the 
ESTST protocol described under ECLTRG Trigger Protocols. 

A Slot 0 module implementing the SYNClOO function will provide an arbiter to synchronize external events to 
CLKIOO and meet the guaranteed setup and hold times for the SYNClOO signal. This guarantees that all 
affected modules will trigger on the same CLKIOO clock edge. SYNClOO is a nominally 10 ns pulse and may 
be initiated by any type of external or internal event: an external BNC trigger, a software register write, the 
state of any of the TTLTRG*, ECLTRG, LBUS or STAR lines or any other signal synchronized by the Slot 0 
arbiter. Refer to the timing diagram on Ligure B. 13. 

OBSERVATION B.6.20: 

SYNClOO delay matching relative to CLKIOO is called out under CLKIOO matching rules. 

RECOMMENDATION B.6.7: 

Slot 0 modules SHALL provide >4.0 ns of setup time from SYNClOO to the rising edge of CLKIOO. 

RULE B.6.89: 

Slot 0 modules SHALL provide >3.5 ns of hold time from rising edge of CLKIOO to SYNClOO. 

RECOMMENDATION B.6.8: 

Slot 0 modules which provide SYNClOO support should be designed such that the SYNClOO recycle rate is 
<50 ns. 
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RULE B.6.90: 

Each module slot SYNClOO SHALL be driven by a unique backplane buffer output. 

RULE B.6.91: 

SYNClOO SHALL be distributed differentially from Slot 0. 

RULE B.6.92: 

The backplane SYNClOO distribution traces SHALL be designed for 50 Q. 

RULE B.6.93: 

The SYNClOO backplane distribution network SHALL NOT insert more than 2.0 ns timing skew between 
SYNClOO signals at any two slots. 

RULE B.6.94: 

IF a module accesses the SYNClOO signals 

THEN it SHALL provide 50 Q termination on SYNC 100+ and SYNClOO-, with no more than two 
equivalent ECL loads. 


B.6.3.3 STARX and STARY 

STARX and STARY provide inter-module asynchronous communication. Two STAR lines are connected 
between each module slot and Slot 0. Slot 0 may provide a cross matrix switch which can programmably route 
signals between any two STARX or STARY lines. It may also broadcast a signal received on one STAR line 
to a group of STAR lines. The STAR lines are bidirectional, providing additional flexibility. 

RULE B.6.95: 

The STARX and STARY backplane distribution network SHALL NOT insert more than 2.0 ns timing skew 
between any two STAR signals. 

RULE B.6.96: 

STARX and STARY SHALL be driven differentially. 

RULE B.6.97: 

The backplane STAR distribution traces SHALL be designed for 50 Q. 

RULE B.6.98: 

IF a module accesses the STAR signals 

THEN it SHALL provide 50 Q termination on STAR+ and STAR-, with no more than a single equivalent 
ECL driver load and a single equivalent ECL receiver load. 

RULE B.6.99: 

Modules which can both drive and receive STARX or STARY SHALL use bidirectional ECL drivers, e.g. 
10H123. When the module is programmed to receive, the STAR+ and STAR- drivers SHALL be forced into 
the high impedance state (Vol < -2.0 V) 

RULE B.6.100: 

A D-size Slot 0 module SHALL provide a default differential signal to all STARX and STARY lines which 
are not being driven by another module. 

PERMISSION B.6.4: 

If a Slot 0 module does not support STAR bus routing, it may meet the above rale by connecting a 50 Q 
resistor between STAR+ lines and ground. 
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RULE B.6.101: 

The absolute delay of any STAR line between Slot 0 and any module SHALL NOT exceed 5 ns. 

RULE B.6.102: 

The backplane SHALL NOT connect to the STARX+, STARX-, STARY+ and ST ARY- pins of the Slot 0 
backplane connector. 

PERMISSION B.6.5: 

The Slot 0 module MAY access the STARX-i-, STARX-, STARY-i- and STARY- pins. 

OBSERVATION B.6.21: 

Allowing all modules, including Slot 0, to access the STAR lines allows construction of modules that may 
operate in any slot position, including Slot 0. 


B.6.3.4 ECLTRG2-5 

These lines are functionally the same as the ECLTRGO-1 lines on P2 described in Section B.6.2.4, 
"ECLTRGO-1" and meet the same rules. 


B.6.3.5 LBUS12-35 

These lines are functionally the same as the LBUSOO-11 lines on P2 described in Section B.6.2.6, "Local Bus" 
and meet the same rules. 


B.6.3.6 RSV4-7 

These lines are functionally the same as the RSV2-3 lines on P2 described in Section B.6.2.7, "RSV2-3" and 
meet the same rules. 


B.6.4 The VXIbus Subsystem PO Connector 

The PO connector used in the VXIbus system conforms to the VME Switched Serial (VXS) standard, 
ANSEVITA 41.6 standard. The VXS based standard defines the physical features that enable high-speed 
communication in the VXIbus system by placing a new connector in the position between the PI and P2. This 
connector is NOT the same as the VME64x PO-JO definition, since it uses different connectors and includes 
keying and alignment pins. 

There is a noticeable difference in the pin-out and assignment of the JO and PO connectors illustrated in Tables 
B.5.1 and B.5.2. The high-speed connectors used do not have a symmetric footprint on the module and the 
backplane. Signal mapping between the PO and JO is relative to the signal names, not the pin numbering. 

You will note that Rows E and G of JO, the Backplane connector, combine to complete Row E of the PO 
Module Connector. Similarly, Rows B and C of JO combine to complete Row B of PO. This mapping of the 
two dissimilar connectors provides for double grounding and better signal integrity. 
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Row G 

Row F 

Row E 

Row D 

Row C 

Row B 

Row A 

1 

PA SCL 

GNT) 

PA TX0- 

PA TX0- 

GNT) 

PA RX0- 

PA RX0+ 

2 

GXD 

PA TXl- 

PA TXl- 

GNT) 

PA RXl- 

PA RX1+ 

GNT) 

3 

PA SDA 

GNT) 

PA TX2- 

PA TX2- 

GNT) 

PA RX2- 

PA RX2+ 

4 

GND 

PA TX3- 

PA TX3- 

GNT) 

PA RX3- 

PA RX3+ 

GNT) 

5 

RFU 

GNT) 

PA SGTX- 

PA SGTX- 

GNT) 

PA SGRX- 

PA SGRX+ 

6 

GND 

RFU 

RFU 

GNT) 

RFU 

RFU 

GNT) 

7 

RFU 

GNT) 

RFU 

RFU 

GNT) 

RFU 

RFU 

S 

GND 

RFU 

RFU 

GNT) 

RFU 

RFU 

GNT) 

9 

RFU 

GNT) 

RFU 

RFU 

GNT) 

RFU 

RFU 

10 

GND 

RFU 

RFU 

GNT) 

RFU 

RFU 

GNT) 

11 

PEN* 

GNT) 

PB SGTX- 

PB SGTX+ 

GNT) 

PB SGRX- 

PB SGRX- 

12 

GNT) 

PB TXO- 

PB TX0+ 

GNT) 

PB RXO- 

PB RXO- 

GNT) 

13 

PB SCL 

GNT) 

PB TX1- 

PB TX1+ 

GNT) 

PB RX1- 

PB RX1- 

14 

GND 

PB TX2- 

PB TX2+ 

GNT) 

PB RX2- 

PB RX2- 

GNT) 

15 

PB_SDA 

GNT) 

PB_TX3- 

PB_TX3+ 

GNT) 

PB_RX3- 

PB_RX3- 


TABLE B.5.1. Module PO Signal Assignments 



Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

Row I 

1 

PA RX0+ 

PA RXO- 

GND 

GND 

PA TX0+ 

PA TXO- 

GND 

GND 

PA SCL 

2 

GNT) 

GND 

PA RX1- 

PA RX1- 

GND 

GND 

PA TX1+ 

PA TX1- 

GNT) 

3 

PA RX2+ 

PA RX2- 

GND 

GND 

PA TX2+ 

PA TX2- 

GND 

GNT) 

PA SDA 

4 

GNT) 

GND 

PA RX3+ 

PA RX3- 

GND 

GNT) 

PA TX3+ 

PA TX3- 

GNT) 

5 

PA SGRX- 

PA SGRXh 

GND 

GND 

PA SGTX+ 

PA SGTX^ 

GND 

GND 

RFU 

6 

GNT) 

GND 

RFU 

RFU 

GND 

GNT) 

RFU 

RFU 

GNT) 

7 

RFU 

RFU 

GND 

GND 

RFU 

RFU 

GND 

GNT) 

RFU 

8 

GNT) 

GND 

RFU 

RFU 

GND 

GNT) 

RFU 

RFU 

GNT) 

9 

RFU 

RFU 

GND 

GND 

RFU 

RFU 

GND 

GND 

RFU 

10 

GNT) 

GND 

RFU 

RFU 

GND 

GNT) 

RFU 

RFU 

GNT) 

11 

PB SGRX- 

PB SGRX- 

GND 

GND 

PB SGTX- 

PB SGTX- 

GND 

GND 

PEN* 

12 

GNT) 

GND 

PB RX0+ 

PB RX0- 

GND 

GNT) 

PB TX0+ 

PB TX0- 

GNT) 

13 

PB RXl- 

PB RXl- 

GND 

GND 

PB TXl- 

PB TXl- 

GND 

GND 

PB SCL 

14 

GNT) 

GND 

PB RX2+ 

PB RX2- 

GND 

GNT) 

PB TX2+ 

PB TX2- 

GNT) 

15 

PB_RX3- 

PB_RX3- 

GND 

GND 

PB_TX3- 

PB_TX3- 

GND 

GNT) 

PB SDA 


TABLE B.5.2. Backplane JO Signal Assignments 
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B.6.5 Backplane 

The backplane is the common signal and power distribution network for all modules. As such, it must be very 
well designed so as not to introduce noise into the system. 

OBSERVATION B.6.22: 

Noise should be minimized on the ECLTRG Lines, Clock lines and SUMBUS lines. It is desirable to maintain 
time jitter to <25 ps. This requires that noise be limited to +9 mV, assuming an ECL slew rate of 2.75 V/ns. 

RULE B.6.103: 

All backplane ECL transmission paths SHALL be designed for 50 Q nominal characteristic impedance. 

OBSERVATION B.6.23: 

When TTL lines share a layer of the backplane with 50 Q ECL transmission lines, the TTL signal 
characteristic impedance may also be near 50 Q. This should provide satisfactory operation (See the VME64 
specification. Observation 6.13). 

SUGGESTION B.6.2: 

See the MECL System Design Handbook, Motorola, for more backplane and microstrip design information. 

B.6.5.1 ECL SIGNAL LEVELS 

The signal levels present on the backplane ECL lines are summarized in Table B.6. 


Symbol 

Parameter 

Minimum 

Typical 

Maximum 

Units 

YOH 

Output logic level “1” (HIGH) 

-0.980 

-0.9 

-0.735 

Volts 

YOL 

Output logic level “0” (LOW) 

-1.950 

-1.75 

-1.630 

Volts 

Ybb 

Logic Switching Threshold 


-1.29 


Volts 


TABLE B.6. Backplane ECL signal levels 
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B.6.6 LVDS Operation 

TIA/EIA-644-A Electrical Characteristics of Low Voltage Differential Signaling (LVDS) is a low voltage, low 
power, differential technology used primarily for point-to-point and multi-drop cable and backplane driving 
applications. TIA/EIA-644-A specifies a maximum data rate of 3.125Gbps with a voltage swing of +350mV. 

Eor a typical LVDS driver and receiver pair in a point-to-point topology, controlled impedance of the 
interconnect, proper driver load, and interconnect termination are the key points for consideration when 
designing for low-jitter signal transmission. Multipoint topologies have multiple signal drivers and receivers all 
sharing a sir^le interconnect. Terminating the signal bus on the far receiver side is advisable only when the signal 
driver is on the opposite end of the bus from the terminated receiver. In all other cases, such as the driver 
connected to the middle of the bus, the bus needs to be terminated at both ends of the bus. 

Differential signaling offers many advantages over single ended technologies. Not only does this result in a 
faster, more stable signal, it also makes migration to lower power supply voltages much easier. Another 
advantage to differential technology is that the balanced differential lines have tightly coupled equal but polar 
opposite signals which reduce EMI. The magnetic fields radiated by each of the conductors are drawn toward 
each other and cancel much of the magnetic fields. 
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B.7 MECHANICAL SPECIFICATIONS 


B.7.1 Introduction 

Information is provided in this chapter to ensure that VXIbus modules, backplanes, mainframes and associated 
mechanical accessories are dimensionally compatible. 

The mechanical dimensions given in this chapter are based on ANSI/IEEE 1101 and lEC publications 297-3 
and 603-2. The electrical characteristics for VXIbus connectors, as specified here, supersede publication 603-2 
where they differ. 

Eigure B. 14 is a front view of a typical VXIbus mainframe. In the mainframe shown, modules are inserted into 
the mainframe from the front, in a vertical plane, with the component face of the module board on the right. 


B.7.2 Module Specifications 


B.7.2.1 VXIbus BOARDS and MODULES 
RULE B.7.1: 

VXIbus modules SHALL fit into one of four size classifications: 

1. Single height module typically containing a board with dimensions 100 mm (3.937 in) high x 160 mm 
(6.299 in) deep will be referred to as a "Size A" module. 

2. Double height module typically containing a board with dimensions 233.35 mm (9.187 in) high x 
160 mm (6.299 in) deep will be referred to as a "Size B" module. 

3. Double height module typically containing a board with dimensions 233.35 mm (9.187 in) high x 
340 mm (13.386 in) deep will be referred to as a "Size C" module. 

4. Triple height module typically containing a board with dimensions 366.7 mm (14.437 in) high x 
340 mm (13.386 in) deep will be referred to as a "Size D" module. 

RULE B.7.2: 

Size A and size B boards and board assemblies SHALL be designed according to the dimensions given in the 
VME64 specification. 

OBSERVATION B.7.1: 

Size A and size B boards and board assemblies are designed for a mainframe with 20.32 mm (0.8 in) spacing 
between slots. 

RULE B.7.3: 

Size C and size D modules SHALL be contained within the envelope specified in Eigures B.17, B.18 and B.21. 

RULE B.7.4: 

Size C and size D modules SHALL be designed for a mainframe with 30.48 mm (1.2 in) spacing between 
slots. 

OBSERVATION B.7.2: 

Typical size C and size D modules will contain a board as shown in Eigures B.15 and B.16. 
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RULE B.7.5: 

Modules SHALL provide the board edge feature as specified in Figure B.21 to allow proper insertion into a 
mainframe. This feature SHALL be 1.6 + 0.2 mm (0.063 +0.008 in) thick. 

RECOMMENDATION B.7.1: 

Design C and D modules around a board as specified in Figures B.15 and B.16. This will ensure proper 
position of connectors, front panel, board edge, etc. 


B.7.2.1.1 Module Connectors 

Size A modules have only one connector, called the PI connector. Size B and C modules have either one or 
two connectors, called the PI and P2 connectors. Size D modules have one, two or three connectors, called the 
PI, P2 and P3 connectors. In all modules, the PI connector is mandatory, P2 and P3 are optional. 

Modules supporting VXS utilize the PO connector positioned between PI and P2. PO can be positioned on Size 
B, C, or D modules. 

RULE B.7.5.1: 

All VXIbus modules SHALL be equipped with the PI connector. 

PERMISSION B.7.1.1: 

Size B and C modules MAY utilize the P2 and PO connector in addition to the PI connector. 

PERMISSION B.7.1.2: 

Size D modules MAY utilize the P2, P3 and PO connector in addition to the PI connector. 

RULE B.7.6: 

PI, P2 and P3 connectors SHALL meet or exceed the mechanical specifications for the 160-pin connector 
defined in lEC 61076-4 family which is complementary to the lEC 603-2 Style C connector. 

PERMISSION B.7.1.3 

Modules providing a connector shield as defined in section B.7.2.3 and Figure B.34 MAY use PI, P2 and P3 
connectors that meet or exceed the mechanical specifications for either the DIN Standard 41612 for Class II, 
Style C, 3 row, 96-pin connectors. 

RULE B.7.6.1 

IF a module/mainframe adds the optional PO/JO connector 

THEN it SHALL be a high-speed connector as defined in ANSI/VITA 41.0-2006, Rule 3.4 

RULE B.7.6.2 

Modules supporting the PO connector SHALL also include the PI connector as defined in Section B.6.1. 

RULE B.7.6.3 

Modules that support PO SHALL incorporate the AO alignment pin and KO key as defined in VITA 41.6 of this 
standard. 

OBSERVATION B.7.3: 

DIN Standard 41612 Class II and IFC 61076-4 Class I family connectors have a minimum mechanical 
endurance of 400 insertion/extraction cycles. 

RULE B.7.7: 

The mounting location of the PO, PI, P2 and P3 connectors SHALL be consistent with the hole patterns 
specified in Figures B.15 and B.16. 
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RULE B.7.8: 

The PO, PI, P2 and P3 connectors SHALL be positioned as shown in Figures B.19 and B.20. 

B.7.2.1.2 Board Assemblies 

The board assembly typically consists of a PC board and connectors, as defined above and electronic 
components. 

RULE B.7.9: 

Solder fillets, traces, shielding and components on VXIbus boards SHALL NOT be closer than 2.5 mm 
(0.098 inches) from the top and bottom edges of the board to guarantee clearance between them and the board 
guides. Figures B.15 and B.16 show these dimensions for size C and D modules. 

RULE B.7.10: 

IF a module contains components sensitive to orientation (e.g. mercury switches), 

THEN that module's specifications and labels SHALL clearly state its limitations. 

RECOMMENDATION B.7.2: 

An orientation sensitive module should be designed to be installed vertically with its component side to the 
right or horizontally with its component side up. 

B.7.2.1.3 Module Width 
PERMISSION B.7.1: 

Size C or D modules which require more than the standard spacing MAY be designed to occupy more than one 
slot, adding an integer multiple of 30.48 mm (1.2 in) to the module width. 

OBSERVATION B.7.4: 

Component height, lead length, shield positions, etc. of the typical module are shown in Figure B.18. 

PERMISSION B.7.2: 

Module shields as shown in Figure B.17 and Figure B.18 MAY be omitted or their positions changed, but must 
remain within the defined envelope. 

RECOMMENDATION B.7.3: 

Include module shields to improve electromagnetic compatibility (EMC), ease of handling, etc. 


B.7.2.1.4 Board Warpage, Lead Length, Shield Height and Component Height 
RULE B.7.11: 

All A and B-size board assemblies SHALL meet the requirements of Section 7.2.6 of the VME64 specification 

RULE B.7.12: 

For shielded C and D-size modules, the outer surface of the solder-side shield, including warpage, SHALL be 
greater than or equal to 1.57 mm (0.062 inch) from the intermodule separation plane when installed. The outer 
surface of the component-side shield, including warpage, SHALL be greater than or equal to 0.15 mm 
(0.006 inch) from the intermodule separation plane when installed. Refer to Figure B.18. 

RECOMMENDATION B.7.4: 

To account for warpage, the nominal solder-side shield should be greater than 2.07 mm (0.082 inch) from the 
intermodule separation plane. The nominal component-side shield should be greater than 0.65mm (0.026 inch) 
from the intermodule separation plane. Refer to Figure B.18. 

RULE B.7.13: 

For unshielded C and D-size modules, leads and solder-side components, including warpage, SHALL be 
greater than or equal to 3.96mm (0.156 inch) from the intermodule separation plane when installed. 
Components, including warpage, SHALL be greater than or equal to 2.54 mm (0.100 inch) from the 
intermodule separation plane when installed. Refer to Figure B.18. 
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B.7.2.2 FRONT PANEL 

This section provides the mechanical specifications for the double and triple height module front panels and 
associated hardware. Figure B.22 shows a double height, single width (C-size) front panel. Figure B.23 shows 
a triple height, single width (D-size) front panel. 

RULE B.7.14: 

All modules SHALL include a front panel. 

RULE B.7.15: 

Fach module, regardless of size, SHALL have a front panel conforming to the size of the mainframe it is used 
in. 

PERMISSION B.7.3: 

Additional hardware MAY be utilized to fill a front panel gap when inserting a small module into a larger 
mainframe. 

RULE B.7.16: 

Front panel screws SHALL be provided to secure the top and bottom of the panel to the mainframe and their 
screw threads SHALL be M2.5 x 0.45 pitch. See Figure B.22. 

RULE B.7.17: 

Front panels SHALL make contact with chassis ground in the area surrounding the retention screws as shown 
in Figure B.22 and Figure B.23. This surface SHALL be conductive, smooth and free of all protrusions. 


B.7.2.2.1 Front Panel Mounting 
RULE B.7.18: 

All modules SHALL comply with the test dimension shown in Figure B.26 and Figure B.27. This dimension 
is from the rear face of the front panel to the rear face of the backplane connector. 


B.7.2.2.2 Front Panel Dimensions 

RULE B.7.19 

Single width C- and D-size front panels SHALL be designed to the dimensions shown in Figure B.22 and 
Figure B.23 respectively. 

RULE B.7.20: 

IF a C- or D-size module occupies more than one slot 

THEN the width of the front panel SHALL be 30.18 mm (1.188 inch) plus an integral multiple (N) of 
30.48 mm (1.200 inch), where N is the number of slots that the module occupies minus one. 

RULE B.7.21: 

IF local bus lockout keys are required on a module, 

THEN the front panel SHALL be notched as shown in Figure B.22 and Figure B.23. 

SUGGESTION B.7.1: 

Include the lockout key notch on all front panels. This will simplify removal of a module when the adjacent 
module is keyed. 


B.7.2.2.3 Filler Panels 
RULE B.7.22: 

Filler panels SHALL be used in any empty slots. 
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OBSERVATION B.7.5: 

Filler panels are often required by safety regulations and may be necessary for cooling and EMC performance. 

RULE B.7.23: 

C- and D-size filler panels SHALL conform to dimensions given in Figure B.24 and Figure B.25 respectively. 

RULE B.7.24: 

A- and B-size filler panels SHALL conform to Section 7.3.4 of the VME64 Specification. 

B.7.2.2.4 Module Injectors/Ejectors 

Insertion and extraction forces of the module relative to the mainframe may be very high. These forces are 
greatest for D-size modules that use all three backplane connectors. 

RECOMMENDATION B.7.5: 

Modules using two or more of the lEC 61076-4 family 160 pin plug connectors should provide an 
injector/ejector system. 

OBSERVATION B.7.6: 

The insertion force for three 96 lEC 61076-4 family 160 pin plug connectors will exceed 270 N (60.69 Ibf). 

PERMISSION B.7.4: 

An injector and /or ejector system MAY be provided on any module size. 

RULE B.7.25: 

Modules equipped with ejectors or injectors SHALL NOT interfere with mainframes designed to the VXIbus 
or VME64 specification. See Figure B.37. 

OBSERVATION B.7.7: 

Refer to Section B.7.3.3, "Injection/Ejection", for more information 

B.7.2.2.5 Front Panel Interface 
RULE B.7.26: 

External wiring to a module, if any, SHALL exit the module only through the front panel area. 

OBSERVATION B.7.8: 

External wiring is defined as any connectors, cables, etc. that carry signals or interfaces out of the mainframe 
in which the module is installed. The above rule does not exclude module-to-module wiring. 

RULE B.7.27: 

Connector and front panel interfaces SHALL NOT leave significant gaps in the front panel or disrupt proper 
airflow within the system. 

OBSERVATION B.7.9: 

Although the terms "significant gaps" and "proper air flow" can be rather broadly interpreted, it is intended that 
a manufacturer be very cautious about the front panel components chosen. 


B.7.2.2.6 Front Panel Handles 
RULE B.7.28: 

Handles SHALL NOT interfere with the local bus lockout keys of adjacent modules. 

SUGGESTION B.7.2: 

Handle width and position should comply with the dimensions shown in Figure B.22 and Figure B.23. This 
will avoid interference with local bus lockout keys. 

OBSERVATION B.7.10: 

Injection and ejection constraints may require the use of a handle with dimensions different than those in 
Figure B.22 and Figure B.23. 
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B.7.2.3 MODULE SHIELDING 

Shields are often included in modules to improve EMC performance, ease of handling, etc. Refer to 
Eigure B.17 and Eigure B.18. 

PERMISSION B.7.5: 

Module shields MAY be tied to chassis ground or circuit ground. 

RULE B.7.29: 

C-size and D-size modules SHALL provide room for the optional mainframe chassis shield as shown in 
Eigure B.17 and Eigure B.18. 

OBSERVATION B.7.11: 

The envelope as defined in Eigure B.17 ensures that module shields do not contact adjacent modules. 

OBSERVATION B.7.12: 

Connector shield contacts may or may not be removable. However, removable contacts may be advisable for 
some modules. The module manufacturer should evaluate the applicability of removable contacts for each 
module. 

PERMISSION B.7.7: 

A module MAY make electrical contact with a compatible adjacent module at any point in the area near the 
front panel as specified in Eigure B.17. This contact may be implemented by means of gasketing, clips, etc. 

RULE B.7.30: 

IF gasketing is installed for contact with a compatible adjacent module, 

THEN it SHALL be installed on the solder side (as defined in Eigure B.17) only and it SHALL be 
compressible to fit within the intermodule separation plane. 

RECOMMENDATION B.7.6: 

Gasketing installed for contact with a compatible adjacent module should be removable. This will allow 
installation adjacent to unshielded or otherwise incompatible modules. 

RECOMMENDATION B.7.7: 

The areas specified in Eigure B.17 for contact with adjacent modules should be chassis ground and conductive. 


B.7.2.4 MODULE COOLING 

Test set-up and procedures for establishing module cooling requirements are detailed in VXI-8, Rev 2.0, 
"Cooling Characterization Methodology Specification"^^^. Module cooling requirement specifications include 
an operating point. The operating point includes three pieces of information: 

The maximum recommended temperature rise of cooling air as it flows through the module (typically 
10°C). 

The airflow required to maintain the recommended temperature rise (in liters/second). 

The pressure drop that is created across the module by the required airflow (in mm H 2 O). 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 



Page 60 


Section B: VXIbus Implementation of VMEbus Specs 


RULE B.7.31: 

Cooling air SHALL flow as shown in Figure B.29, FigureB.30 and Figure B.38. Airflow direction is from P3 
to PI. 

RULE B.7.32: 

Cooling requirements SHALL be established for all modules and included in product specifications. 

RULE B.7.33: 

Module cooling requirement specifications SHALL be in compliance with Specification VXI-8. The 
specifications SHALL include the maximum ambient operating temperature and the operating point. 
(Example: 55°C ambient maximum operating temperature. For 10°C internal rise, 0.5 mm H 2 O @ 
1.5 liters/second) 

B.7.2.5 MODULE POWER 
RECOMMENDATION B.7.8: 

Attach an abbreviated version of the power supply voltage and current requirements to the module. This will 
facilitate system integration. 


B.7.2.6 MODULE KEYING 

Module keying for the optional PO connector is illustrated in Figure B.15., but details of the alignment and 
keying properties are discussed in Section B.13. 

Lockout keys are provided to serve as an impediment to local bus incompatibilities. 

RULE B.7.34: 

IF modules access a local bus, 

THEN lockout keys SHALL be provided, consistent with the particular bus accessed. The lockout keys 
SHALL conform to the specifications in Figure B.28. 

RULE B.7.35: 

IF lockout keys are required on a module, 

THEN they SHALL be installed by the manufacturer, consistent with the definition of the product. 

OBSERVATION B.7.13: 

Lockout keys are not intended to provide failsafe protection. Accidental damage may still occur if 
incompatible modules are forced next to each other on the local bus. 


B.7.2.7 MODULE ENVIRONMENTAL 
RECOMMENDATION B.7.9: 

Test modules for temperature, humidity, vibration, shock, etc., according to the procedures described in lEC 
Publication 68. Include the results in product specifications, along with module mass. 

OBSERVATION B.7.14: 

It is a system integrator's responsibility to select modules and mainframes appropriate for the application's 
environmental requirements. 
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B.7.3 Mainframe Specifications 

RULE B.7.36: 

VXIbus mainframes SHALL fit into one of four size classifications: 

1. A mainframe that provides the J1 backplane and allows the insertion of an A-size module, only, 
will be referred to as an "A-size" mainframe and conform to the VME64 specifications for 
subracks. 

2. A mainframe that allows the insertion of a B-size module, maximum, will be referred to as a 
"B-size" mainframe and conform to the VME64 specifications for subracks. The J1 backplane is 
mandatory, J2 is optional. 

3. A mainframe that allows the insertion of a C-size module, maximum, will be referred to as a 
"C-size" mainframe. The J1 backplane is mandatory, J2 is optional. 

4. A mainframe that allows the insertion of a D-size module, maximum, will be referred to as a 
"D-size" mainframe. The J1 backplane is mandatory, J2 and J3 are optional. 

RECOMMENDATION B.7.10: 

Allowances should be made for the insertion of A-size modules into B-size mainframes, the insertion of A- and 
B-size modules into C-size mainframes and the insertion of A-, B- and C-size modules into D-size mainframes. 

OBSERVATION B.7.15: 

Additional hardware and removable module guides may be required to allow the insertion of smaller modules 
into a larger mainframe. 

RULE B.7.37 

IF the insertion of smaller modules is allowed into a larger mainframe, 

THEN the mainframe manufacturer SHALL specify a procedure and/or means for the insertion of the smaller 
modules. 

PERMISSION B.7.8: 

Mechanical and/or electrical means may be used for the adaptation of a smaller module to a larger mainframe. 

RULE B.7.38: 

C- and D-size mainframes SHALL be designed for 30.48 mm (1.2 in) slot spacing, as shown in Eigure B.30. 

RULE B.7.39: 

A and B-size mainframes SHALL be designed to 20.32 mm (0.8 inch) spacing. 

RULE B.7.40: 

C- and D-size mainframes SHALL conform to the dimensions and tolerances shown in Eigure B.29 and Eigure 
B.30. This ensures that connectors mate properly and that modules will fit in the mainframe without 
interference. 

RULE B.7.41: 

With the mainframe oriented with the modules vertical, PI at the top, component side of module boards to the 
right; Slot 0 SHALL be the left most slot of any VXIbus subsystem. 

OBSERVATION B.7.16: 

This rale does not mandate mainframe orientation; it only establishes the position of Slot 0 relative to 
mainframe orientation. 
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SUGGESTION B.7.3: 

IF vertical orientation of the modules is desired, 

THEN Slot 0 should be at the left. 

IF horizontal orientation of the modules is desired, 

THEN Slot 0 should be at the bottom. 

RULE B.7.42: 

Module guides SHALL be made of non-conductive material or be isolated from chassis ground. 


B.7.3.1 BACKPLANES 

RULE B.7.43: 

Each backplane SHALL be a single monolithic board, within any slot position. 

RULE B.7.44: 

Backplane connectors for C and D-size mainframes SHALL be positioned as shown in Eigures B.31 and B.32. 

PERMISSION B.7.9: 

Backplanes MAY deviate from Eigure B.31 and Eigure B.32 in structure and mounting methods. 

OBSERVATION B.7.17: 

Typical C and D-size backplanes are shown in Eigure B.31 and Eigure B.32 for reference. Adherence to these 
drawings will ease the task of mounting and aligning the backplane within the mainframe. 

RULE B.7.45: 

IF components other than connectors are placed on the component side of A-size C or D backplane, 
THEN they SHALL be placed outside the shaded areas specified in Figure B.33. Non-conductive 
components SHALL be less than 12.2 mm (0.480 inch) in height. Conductive components SHALL be less 
than 10.0 mm (0.394 inch) in height. 

RULE B.7.46: 

Connector shields SHALL comply with Figure B.34. 

RULE B.7.47: 

IF conductive backplane traces are exposed within the ground ring area defined by Figure B.33, 

THEN fhe pofenfial of fhose fraces SHALL be circuif ground. 

RULE B.7.48: 

Componenfs SHALL NOT be locafed near backplane connectors as specified in Figure B.33. 

RULE B.7.49: 

DIN Sfandard 41612 Class II, Sfyle C, 3 row, 96-pin sockef type connecfors SHALL be used on fhe J3 
posifion. lEC 61076-4 160-pin connectors SHALL be used on J1 and J2 positions. 

RULE B.7.50: 

The VXIbus J1 bus SHALL have some provision for manual or automatic jumpering fhe inferrupf 
acknowledge and bus granf daisy-chains when boards are nol plugged into a slof. 
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B.7.3.2 GROUNDING 
OBSERVATION B.7.18: 

Mainframes may connect circuit ground to chassis ground. 

RULE B.7.51: 

All mainframes SHALL provide chassis ground to the module front panels in the area of the front panel 
mounting screws. The chassis ground contact area is shown in Figure B.22 for C-size modules and in Figure 
B.23 for D-size modules. 


B.7.3.3 INJECTION, EJECTION and DETECTION 
RULE B.7.52: 

Mainframes SHALL provide a surface for module extraction as shown in Figure B.37. 

RECOMMENDATION B.7.12: 

Mainframes should provide a surface for module injection, as shown in Figure B.37. 

RULE B.7.53: 

Mainframes SHALL NOT interfere with injector/ejector systems conforming to Figure B.37. 

RECOMMENDATION B.7.13: 

If module detection mechanisms are included in a mainframe, their actuators should be positioned to contact 
the module front panels on the surface defined in Figure B.22 and B.23. 

OBSERVATION B.7.19: 

Module detection mechanisms can be used to actuate airflow control shutters. 

SUGGESTION B.7.4: 

Make module detection mechanisms removable, in order to allow integration of modules that are incompatible 
with the detection mechanisms. 


B.7.3.4 MAINFRAME SHIELDING 
PERMISSION B.7.10: 

Mainframes MAY allow the installation of a chassis potential shield as shown in Figure B.17 and Figure B.18. 

RULE B.7.54: 

IF mainframe chassis shields are provided, 

THEN they SHALL be removable. 

RULE B.7.55: 

IF the shield potential of a module is not chassis ground or the module is unshielded, 

THEN any adjacent chassis shield SHALL be insulated. 

PERMISSION B.7.11: 

IF the shield potential of a module is defined as chassis ground, 

THEN electrical contact between the module and adjacent chassis shields MAY be allowed. 

RECOMMENDATION B.7.14: 

IF a mainframe has provision for chassis shields, 

THEN both insulated and non-insulated shields should be available. 
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B.7.3.5 MAINFRAME COOLING 

Test set-up and procedures for establishing mainframe cooling requirements are detailed in VXI-8, Rev 2.0, 
"Cooling Characterization Methodology Specification". 

RULE B.7.56: 

IF a mainframe provides cooling air, 

THEN it SHALL supply the air to each slot in the minimum area specified in Figure B.38. 

RULE B.7.57: 

IF a mainframe provides cooling air, 

THEN that mainframe SHALL provide room for the exhausted cooling air to exit each slot in the minimum 
area specified in Figure B.38. 

PERMISSION B.7.12: 

A mainframe MAY provide for additional cooling air entry and exhaust in areas outside those specified in 
Figure B.38. 

RULE B.7.58: 

Cooling specificalions SHALL be esfablished for ah mainframes and included in fhe producf specificalions. 

RULE B.7.59: 

Mainframe cooling specificalions SHALL be in compliance wilh Specificalion VXI-8. These specificalions 
SHALL include a minimum performance curve, Ap (in mm H 2 O) vs. airflow (in lilers/second), a figure of 
meril for fhe airflow varialion (in %) wilhin a single slol and fhe condilions under which fhe measuremenls 
were made. See Figure B.39. 

PERMISSION B.7.13: 

Mainframe cooling specificalions MAY include a power dissipalion specificalion (in Walls/slol), derived in 
accordance wilh VXI-8. 


B.7.3.6 MAINFRAME POWER 
RECOMMENDATION B.7.15: 

Label fhe mainframe wilh an abbreviated version of fhe power supply specificalions. This label should specify 
available currenl of fhe supply vollages and slate whelher circuil ground is connected lo chassis ground. This 
will facililale system inlegralion. 


B.7.3.7 KEYING 

RULE B.7.60: 

Mainframes SHALL provide local bus lockoul keys for Slol 0. These keys SHALL allow only TTF 
compalible modules on P2 and only ECL compalible modules on P3. See Figure B.28. 

OBSERVATION B.7.20: 

Mainframe lockoul keys typically consisl of a lab or recess lo Ihe left of Slol 0. See Figure B.14. 
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B.7.3.8 MAINFRAME ENVIRONMENTAL 
RECOMMENDATION B.7.16: 

Test mainframes for temperature, humidity, vibration, shock, etc., according to the procedures described in 
lEC Publication 68. Include the results in product specifications. 

SUGGESTION B.7.5: 

Include specifications for the vibration and shock environment experienced by modules installed in a 
mainframe during testing of the mainframe. This should include a variety of module weights and slot 
positions. 

OBSERVATION B.7.21: 

It is a system integrator's responsibility to select modules and mainframes appropriate for the application's 
environmental requirements. 
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3'>OCO_0 3 



NOTES: 

1. All dimensions are shown in millimeters. 

Inch dimensions are shown in parenthesis. 

2. Front panel mounting holes are suggestions only. 

3. OBSERVATION: PI is required for VXI modules. PO, P2 and AO/KO are optional. 

4. OBSERVATION: PI and P2 hole patterns shown are for the lEC 61076-4 5-row, 160-pin 
connector. Modules utilizing the 3-row, 96-pin DIN 41612 connector for PI and P2 need 
only holes for rows ‘a’, ‘b’ and ‘c’. 

5. OBSERVATION: Board outline may be reduced to accommodate shielding. 

Figure B.15. Size C board with PI, P2, and PO 
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NOTES: 

1. All dimensions are shown in millimeters. 

Inch dimensions are shown in parenthesis. 

2. Front panel mounting holes are suggestions only. 

3. OBSERVATION: PI is required for VXI modules. PO, P2,P3 and AO/KO are optional. 

4. OBSERVATION: PI, P2 and P3 hole patterns shown are for the lEC 61076-4 5-row, 

160-pin connector. Modules utilizing the 3-row, 96-pin DIN 41612 connector for PI, P2 
and P3 need only holes for rows ‘a’, ‘b’ and ‘c’. 

5. OBSERVATION: Board outline may be reduced to accommodate shielding 


Figure B.16. Size D board with PI, P2, and P3 
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^ 5 X 2.54 = 12.7 [0.51 



NOTES: 

1 AU daensions ore shown In mliiiielers Inch diaenslons ore shown in paeniheses 

2. For oddihonal information regardng the ollowed thickness of boards, refer to the section tIocUe Width' 

3 This 96 am 10360 mchl dmension is the some regardless of the thickness of the board 

4 Refer to Ihe sechon 'Conponenl Height. Leod Length. Shetd Height and Warpoge*. 

5 This area may be used for etecirical contact with conpaltle adjacent modules. Refer to the section 
■Module Shelbng' 

6 View A-A. See fgife 'Module Envelope. Front View' and figure Tlodule Edge Guide Fealtre' 

7 Refer to Ihe sechon 'Bockplanes' rule on maxioun component height, and Ihe sechon 'Module Shielding' 
observoiion on box type plug-in unrts 


Figure B.17. Module envelope, top view 
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V 


EXAMPLE 

SHIELDED 

MODULE 


V 


EXAMPLE 

SHIELDED 

MODULE 


V 


EXAMPLE 

UNSHIELDED 

MODULE 


V 



INTERMODULE SEPARATION PLANES 


NOTES: 

1. All dimensions ore shown in millimeters. Inch dimensions ore shown in parentheses. 

2. Refer lo the section. 'Componenl Height, Lead Length, Shield Height and Worpoge’. 

3. Minimum shield clearance refers la module when installed and includes the effects af 
warpage. RECOMMENDATION: Nominal clearance should be at least 0.5 (0.020) greater. 

4. Na resiriclians are placed on components inside a shielded module. 

5. Applies only lo unshielded components and leads. 

6. OBSERVATION: Extreme care must be taken with unshielded madules. Safely, handling, 
voltage, warpage, etc. should be considered. 

7. RULE: IF provided, THEN Ihe chassis shield MUST canfarm la these dimensions. 


Figure B.18. Module envelope, front view 
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Figure B.19. C -size board assembly connector positions 
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DIM C (See Note 3) 
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— 2X DIM A 

-—2X 1.6 ±0.2 
(0.063 ± 0.008) 



rsi 


o o 

c:> CD 


o m 
o o 

CQ 


MODULE 

SIZE 

DIMA 

DIM B 

DIM C 

A 

4.07 

100.0 

105.3 


(0.160) 

(3.927) 

(4.146) 

B 

4.07 

233.35 

238.65 


(0.160) 

(9. 187) 

(9.396) 

0 

9. 15 

233.35 

238.65 


(0.360) 

(9. 187) 

(9.396) 

D 

9. 15 

366.70 

372.0 


(0.360) 

( 14 . 437) 

(14.646) 


NOTES: 

1. All dimensions shown in millimeters. Inch 
dimensions are shown in parentheses. 

2. Refer to the figure "Module Envelope, Top 
View”, View A-A. 

3. Restnclion imposed by injector surfaces. 
Refer to Ihe section "Module Shielding”, 

ond to the figure "Module Injection Surface”. 



INTERMODULE SEPARATION RLANE 


Figure B.21. Module edge guide feature 
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2. Dimensions given for heighl. depth ond position of 
hondles ore suggestions only. DETAIL A 


3. RECOMMENDATION 

Locate the mounting hole 12.70 mm (0.500 m) from 
the intermodule separation plane. 

PERMISSION 

The mounting hole may be located 17.78 mm (0.700 in) 
from the intermodule separation plane. 

4. Contact surface used to actuate madule detection mechanisms. 
Surface shall be flush wilh rear surface of panel. 


Figure B.22. C -size Front panel details 
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NOTES: 

1. All dimensions ore shown in millimeters. Inch dimensions ore shown in 
parentheses. 

2. Dimensions given for height, depth and position of handtes are 
suggestions onty. 

3. RECOMMENDATtON 

Locate the mounting hole 12.70 mm (0.500 in) from the intermodule 
separation ptane. 

PERMISSION 

The mounting hote MAY be located 17.78 mm (0.700 in) from the intermodule 
separation ptane. 


Figure B.23. D-size Front panel details (DEPRECATED) 
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NOTES: 

1. All dimensions ore shown in millimeters. Inch dimensions ore shown in 
parentheses. 

2. RECOMMENTATtON 

Where a panel is more Ihon 30.48 mm (1.200 in) wide, use at least 4 
mounting holes, two at the top and two at the bottom. 

3. SUGGESTION 

tF handles ore used on filler panels. 

THEN they should be positioned os shown in front panel detail. 


Figure B.24. C-size filler panel 
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NOTES: 



1. All dimensions are shown m millimelers. Inch dimensions ore shown m 
parentheses. 

2. RECOMMENTATION 

Where a panel is more than 30.48 mm (1.200 in) wide, use al least 4 
maunling holes. Iwo at the top and Iwo al the bottom. 

3. SUGGESTION 

IF handles are used on filler panels. 

THEN they should be posilioned as shawn in front panel detail. 


Figure B.25. D-size filler panel (DEPRECATED) 
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TEST DIMENSION 



1. All dimensions are shown in millimeters. 

Inch dimensions ore shown in parentheses. 

2. Dimensions For front panel mounting brackets are 
suggeslians only. Mounting methods may vary. 


Figure B.26. Typical C-size front panel mounting and dimensions 
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TEST DIMENSION 



1. All dimensions are shown in millimelers. 

Inch dimensions ore shown in parentheses. 

2. Dimensions for Front panel mounting brockets ore 
suggestions only. Mounting methods may vary. 


Figure B.27. Typical D-size front panel mounting and dimensions (DEPRECATED) 
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NOTES: 

1. Dimensions are in mm. Inch dimensions 
are in parentheses. 

2 The example shown is keyed for TTL on 
P2 and Analog Low an P3. 


KEY NOMENCLATURE EXAMPLE: 


LOCAL BUS CONNECTOR, P2 OR P3- 

SIDE OE MODULE, A OR C- 

KEY NUMBER, 0 THRU 3 - 


LOCAL BUS LOCKOUT KEY POSITIONS 



C lass 

I 

C lass 

C lass 

C I ass 

C I ass 

CI ass 



1 



1 

I 

I 

2 

3 

4 

5 


6 


No 


1 

1 



TTL 

I 

ECL 

Ana Iog 

Ana Iog 

Ana Iog 

Resrvd 

Loco I 

Sensor 

1 

Sensor 



I 


Low 

Med 

Hi 

gh 



Bus 

t16V 

1 

i42V 


A C 

I 

A C 

A C 

A C 

A 

C 

A 

C 

A C 

A C 

1 

A C 

Key 


I 










1 


0 

X - 

I 

- X 

X - 

X - 

- 

X 

- 

X 

- - 

X - 

1 

- - 

1 

X - 

I 

- X 

- X 

- X 

X 

- 

X 

- 

- - 

- X 

1 

- - 

2 

- X 

I 

X - 

X - 

- X 

- 

X 

X 

- 

- - 

- - 

1 

- - 

3 

- X 

I 

I 

X - 

- X 

X - 

X 



X 



1 

1 



X Key Present 


Figure B.28. Local bus lockout key details 
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FRONT VIEW 


RIGHT SIDE VIEW 



MOUNTING SURFACE 


NOTES: 

1. All dimensions are shown m millimelers. 

Inch dimensions ore shown m porenlheses. 

2. PERMISSION 

Side plates MAY be extended lo the rear 
os required. 



MINIMUM MOUNTING 
HOLE REOUIREMENTS 


Figure B.29. C -size mainframe drawing 
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FRONT VIEW 
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SEE DETAIL A' 
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VXI FRONT PANEL 
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NOTES: 

1. All dimensions are shown in millimelers. 

Inch dimensions ore shown in parentheses. 

2. PERMISSION 

Side plates MAY be extended lo the rear 
as required. 
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Figure B.30. D-size mainframe drawing (DEPRECATED) 
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VIEWED FROM FRONT OF MAINFRAME 


NOTES: 

1. All dimensions ore shown in millimeters. Inch dimensions 
ore shown in parentheses. 

2. Backplane width varies depending on Ihe number of slots. 

3. These dimensions ore shown os suggestions only. (See Backplane sec Man) 


Figure B.31. C -size backplane drawing 
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VIEWED FROM FRONT OF MAINFRAME 


NOTES: 

1. All dimensions ore shown in millimelers. Inch dimensions 
ore shown in porenlheses. 

2. Backplane width vanes depending on the number of slots. 

3. These dimensions ore shown os suggestions only. (See Backplane section) 


Figure B.32. D-size backplane drawing (DEPRECATED) 
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12.70 (0.500) H 


122.50 

(4.823) 


21.88 

(0.861) 


78.74 (3.10) 
31 PITCHES 
OF 2.54 



CONNECTOR MOUNTING HOLE 
2.7 iO.1 DIAMETER 
(0.106 sO.004) 

SEE NOTE 4 


17.78 (0.700) 
SEE NOTE 2 

20.32 (0.80) - 
SEE NOTE 3 


SUGGESTED MOUNTING 
HOLE POSITION 
2.7 tO.1 DIAMETER 
(0.106 t0.004) 


NOTES: 

1. All dimensions are shown in millimelers. Inch dimensions 
□re shown in pcrenlheses. 

2. Minimim area of graund plane for module shield grounding 
ring around all J1. J2 and J3 conneclors. (See MAINFRAME 
SHIELDING sec lion) 

3. No componenis Ihis area excepi 96-pin connector. 

4. Connector mounting hole may be required by connector shield, etc. 


Figure B.33. Detailed backplane dimensions 
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Flange 


Module Conlact 


Backplane Contacl 


NOTES: 


1. All dimensions 
2 RULE: 

3, RULE: 

4, PERMISSION: 

5, RULE: 

6, RULE: 

7 RULE: 

8, RULE: 

9, PERMISSION: 

10, OBSERVATION, 


11, SUGGESTION: 

12. OBSERVATION, 


are shown in millimelers Inch dimensions are shown in porenlheses. 

Module contacts SHALL be compatible witb the backplane contoct dimensions shown. 

Module conlaci design SHALL NOT impede moling of Ihe backplane connectors. Sufficient spring conlaci flexure 
and lead-in is required. 

Backplane conlacis MAY or MAY NOT extend around Ihe end of fhe backplane connecfor as shown, Nofe fhaf board 
guides prevent module conlacis from exiending around fhe end. 

All module conlacis SHALL be compatible with backplane conlacis lhal extend around Ihe end of fhe backplane 
connector, 

Confocf maferials SHALL be galvanically compatible with Tin/Leod, 

Contact life SHALL be consistent witb the module and backplane connectors 

Connecfor shields SHALL NOT increase insertion force by greater than 50% above fhe module and backplane 
connectors. 

Module conlocis ond backplane conlacis MAY or MAY NOT be removable. 

Removable contacts allow the user to eliminate Ihe connector shield This may be useful for some 
applications. Example: Circuil ground may be isolated from chassis ground. Module manufacturers should 
evaluate Ihe applicability of removable conlacis for each module. 

Mount backplane conlacis lo Ihe backplane connector mounting holes. 

Primary function is rfi shielding, not low impedence ground path. Performance will vary with implementation 


Figure B.34. Backplane connector shield for 96-pin connectors 
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8.36 (0.329) -H 



A A 

INTERMODULE SEPARATION PLANES 


NOTES: 

1. All dimensions are shown in millimelers. Inch dimensions 
ore shown m porenlheses. 

2. Maximum molenal condilion is shown. Module guides may nol be conlmuous across 
the full widlh of the slot. Non-conlmuous guides may accommodate intermodule 
chassis shields, box-slyle units per IEEE 1101. etc. 


Figure B.35. C -size module guide detail 
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8.36 (0.329) ^ 


A A 

INTERMODULE SEPARATION PLANES 


NOTES: 

1. All dimensions ore shown in millimelers. Inch dimensions 
ore shown in parentheses. 

2. Maximum moleriol condilion is shown. Module guides may nol be continuous across 
the full width of the slot. Non-contmuous guides may accommodate intermodule 
chassis shields, box-style units per IEEE 1101. etc. 


Figure B.36. D-size module guide detail (DEPRECATED) 
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NOTES: 

1. All dimensions are shown in millimeters. Inch dimensions 
ore shown in parentheses. 

2. Drawing depicts bottom horizontal rail. Tap horizontal rail is similar. 

3. The Injector Surface is nat required. IF the tnjectar Surface is included in a 
mainframe. THEN it SHALL be continuous within 9.0 mm (0.354 in) either side of 
the modute guide slot centerline. 


Figure B.37. Module injection and ejection surfaces 
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All Specificalions per VXI-8: 

« From lo Rear Airflow Vonolion: 27% worsl case 
» Measuremenl Condilions: 

- High Fan Speed 

- Air Fillers Installed 

« VXI-8 Rawer Raling: ^0 Walls/slol 


NOTES: 

1. IF the madule operating point lolls below the minimuni performance curve. THEN the 
module will receive adequale cooling. IF Ihe module operaling point falls above Ihe 
the minimum performance curve. THEN Ihe module may nol receive adequate cooling. 


Figure B.39. Example of mainframe cooling specification 
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B.8 EMC and SYSTEM POWER 


B.8.1 Introduction 

The VXIbus backplane is governed by the following rules. 

RULE B.8.1: 

VXIbus subsystems SHALL provide power conductors for distribution of +3.3V, +5 V, +5 STDBY, +12 V, - 
12 V, +24 V, -24 V, -5.2 V and -2 V to all of the power pins specified in the pin assignments. 


B.8.2 Power Distribution 

Power in a VXIbus system is distributed on the backplane as regulated direct current (DC) voltages. The 
available voltages are: 

+5 VDC Some systems require this voltage for bus communications and has been the main supply 

voltage until the introduction of the +3.3V supply. 


+3.3 VDC 
+/-12 VDC 

+/-24 VDC 

-5.2 VDC 
-2 VDC 

+5 VDC STDBY 


This supply can be used rather than regulating the 5V supply, which requires module real 
estate and wastes module power through regulation. 

These are often used for powering analog devices, disc drives and communication 
interfaces. 

These are used for powering analog signal sources and to derive other voltage levels (e.g. 
+/-15 VDC) as needed using on-board regulators. 

This is used for ECL devices. 

This is used for termination of ECL loads. 

This is used to sustain memory, clocks, etc. when the +5 VDC power is lost. 


B.8.3 Power Pins 

RULE B.8.2: 

The current flow per pin on any connector SHALL comply with Eigure 5-7 in the VME64 specification based 
on temperature rise considerations in the target system. 

OBSERVATION B.8.1 

A 1 ampere per pin limit allows the VMEbus rated connector to operate at 55 °C ambient. 

RULE B.8.2.1: 

P1/P2 connectors SHALL use VITA 1.7 compliant connectors to draw more power. 


B.8.4 DC Voltage Specifications 

RULE B.8.3: 

Any voltage furnished by the mainframe power supply SHALL comply with the maximum Allowed Variation 
and maximum allowed DC Load Ripple/Noise in Table B.7, up to the mainframe's maximum rated current 
(Imp)- 
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VOLTAGE 

DESCRIPTION 

ALLOWED VARIATION 

DC LOAD 
RIPPLE/NOISE 

INDUCED 

RIPPLE/NOISE 

-h5 V 

-h5 VDC 

-hO.25 V/-0.I25 V 

50 mV 

50 mV 

-h3.3V 

-h3.3V 

-hO.3 V/-0.3 V 

50 mV 

50 mV 

-hl2 V 

-hI2 VDC 

-hO.60 V/-0.36 V 

50 mV 

50 mV 

-12 V 

-12 VDC 

-0.60 V/-h0.36 V 

50 mV 

50 mV 

-h24 V 

-h24 VDC 

-I-I.20 V/-0.72 V 

150 mV 

150 mV 

-24 V 

-24 VDC 

-1.20 V/-I-0.72 V 

150 mV 

150 mV 

-5.2 V 

-5.2 VDC 

-0.260 V/-0.I56V 

50 mV 

50 mV 

-2 V 

-2 VDC 

-O.IO V/-h0.I0 V 

50 mV 

50 mV 

-1-5 V STDBY 

-1-5 VDC standby 

-hO.25 V/-0.I25 V 

50 mV 

50 mV 


TABLE B.7. Power Supply Voltage Specifications 


DC Load Ripple/Noise is the maximum Periodic And Random Deviations (PARD) generated by the 
power supply under all DC load conditions up to the Mainframe Peak Current, measured as the peak- 
to-peak voltage in the DC to 10 MHz bandwidth. This is the Vml parameter in Figure B.41 and 
Figure B.43. 

Induced Ripple/Noise is the additional peak-to-peak ripple that may exist on the backplane power 
supply pins due to injected current from operating modules. This is the Vmi parameter in Figure B.41 
and Figure B.43. 

Mainframe Peak Current (Imp) is the rated DC current of a particular voltage supplied by the 
mainframe. 

Mainframe Dynamic Current (Imd) is the rated dynamic current capacity of a particular voltage 
supplied by the mainframe for the frequencies from 20 Hz to 1 GHz. 

RULE B.8.4: 

Power Supplies source power to the modules and SHALL NOT be used to sink power other than transient 
current from protection circuits. 

OBSERVATION B.8.2: 

The non-symmetric variation given in Table B.7 ensures that the DC power remains within the tolerance 
required by most ICs despite the typical voltage drops that occur in the power distribution network. Placing 
the power supply sense point near the power input point prevents boards near the power input point from 
receiving too high a voltage. 

RULE B.8.5: 

All voltages which are supplied by a mainframe SHALL tolerate peak to peak current variations of Imp from 
DC to 20 Hz without generating peak to peak voltage variations in the DC to 20 Hz frequency range exceeding 
the Induced Ripple/Noise limit of Table B.7. 

RULE B.8.6: 

All voltages which are supplied by a mainframe SHALL tolerate peak to peak current variations as specified 
by the Max. Rated Mainframe Dynamic Current (Imd) in Figure B.40 without generating total (Induced and 
Load Ripple/Noise) peak to peak voltage variations exceeding the limits specified in Figure B.41.For the test 
method see Section B.8.7.2 "Induced Ripple Noise Test of Mainframes". Imd is the rated dynamic current of 
the mainframe supply. Vmi is the peak-to-peak Induced Ripple/Noise specified in Table B.3. Vml is the peak- 
to-peak DC Load Ripple/Noise specified in Table B.7. Slots is the number of VXIbus module slots in the 
mainframe. 
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Slots 

Figure B.40. Mainframe Load Current 



20 Hz 20 kHz 20 kHz 10 MHz 20 MHz 1 GHz 


Figure B.41. Mainframe Induced and Load Ripple/Noise Voltage Limits 


OBSERVATION B.8.3: 

The rated Mainframe Dynamic Current (Jmd) is chosen by the manufacturer to ensure compliance with the 
above Induced Ripple/Noise specification. 
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B.8.5 Power Management 

The power compatibility of mainframes and modules is accomplished by documenting the mainframe output 
power (both peak and dynamic) and module input power (both peak and dynamic). Mainframe power supplies 
will identify all voltage and current capabilities which are present in the mainframe. Modules will identify ah 
voltage and input current requirements for proper operation. This documentation of the power requirements 
will allow the system integrator to verify compatibility between mainframe output power capability and 
module supply requirements. 

Successful integration of a VXIbus instrument system depends on the power compatibility of mainframes and 
modules. The individual dynamic currents of modules will add together to form complex dynamic currents 
that the mainframe must tolerate in order to maintain its ripple specifications. The VXIbus rules establish a 
minimum level of mainframe and module documentation with which the manufacturer must comply. 

Peak Module Current (!/>„) is the maximum rated instantaneous current measured in the DC to 10 MHz 
bandwidth which is drawn by a module for a particular supply voltage during normal operation. 

Dynamic Module Current (lom) is the maximum rated dynamic current required by the module. lom is chosen 
by the manufacturer so that the module meets the conducted emission test from 20 Hz to 1 GHz. 

RULE B.8.7: 

Mainframe Peak Current (Imp) and Mainframe Dynamic Current (\md) SHALL be documented by the 
mainframe manufacturer for every voltage, even if not supported. 

RECOMMENDATION B.8.1: 

Mainframe should be marked with current rating of all voltages listed even if not supplied. 

Example: +5 V STDBY = 0.0 A Peak, 0.0 A Dynamic (if not supported). 

RULE B.8.8: 

Peak Module Current (!/.„) and Dynamic Module Current (Vond SHALL be documented by the module 
manufacturer for all power supply voltages used. 

RECOMMENDATION B.8.2: 

Modules should be marked with input current specifications for ah voltages used. 

OBSERVATION B.8.4: 

The module peak current is measured with a 10 MHz bandwidth instrument to ensure that contributions from 
ah potentially significant frequency components are included. Eor proper operation, the peak current capacity 
of the mainframe (Imp) is required to exceed the sum of the Peak Module Currents (Ipm) for each supply used. 
If the dynamic current capacity of the mainframe (Imd) exceeds the sum of the dynamic current requirements of 
the modules (I/jm), then proper power supply ripple performance is also guaranteed. However, if the dynamic 
currents of the modules exceed that of the mainframe, the specified ripple limits might be exceeded and more 
detailed specifications are required from the mainframe and module manufacturer(s). 

The final determination of compatibility may be application specific. The mainframe manufacturer may 
provide a curve that shows the mainframe dynamic current versus frequency. The module manufacturer may 
provide dynamic module input current versus frequency for particular applications. Eor example, a pulse 
generator that can drive 10 volts into 50 ohms could have curves for 50 ohms, 75 ohms, etc. The module 
manufacturer may also provide voltage ripple specifications for the module if it is more tolerant than the 
VXIbus specification defined in Table B.7. 

OBSERVATION B.8.5: 

The required currenf specificalions of mainframes and modules reflecl fhe producfs in an operafional slate after 
power up. Mainframes and modules mighl acl differenlly during fhe power-up process. 
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RECOMMENDATION B.8.3: 

Mainframes should handle large inrush currents at power up gracefully, without shutting down. 

RECOMMENDATION B.8.4: 

Design a module to present a reasonable load to the mainframe power supplies during the power up period. 
The DC current required by the module, when it is powered by any DC voltage between 0 and Vjuppiy, should 
not exceed the current drawn from an equivalent resistive load of Inrush current, due to a module's 

supply capacitance while the power supply voltage is increasing, is allowed to exceed this value. Limit the 
module's input capacitance to 200 //F or less on each supply voltage used. Design module turn on currents, 
such as may be required for ovens and disk drives, to comply with the module's peak and dynamic current 
specifications. These restrictions allow a VXIbus system to behave gracefully during the power-up period. 


B.8.6 Electromagnetic Compatibility (EMC) of Modules 


B.8.6.1 CONDUCTED EMISSIONS 

RULE B.8.9: 

The maximum instantaneous current drawn by a module SHALL NOT exceed the Peak Module Current (Ip„) 
specified by its manufacturer for any power supply voltage used. 

RULE B.8.10: 

Each module SHALL have less conducted emissions than the levels specified by fhe Max. Rafed Dynamic 
Module Inpuf Currenf in Figure B.42 on all power supply volfages used. For fesf mefhod see B.8.7.3. lom is 
fhe Dynamic Module Currenf of fhe module as specified by ifs manufaclurer. 

RULE B.8.11: 

IF a module's lom or Ip„ is dependenf on a parficular configuralion or sef of configuralions, 

THEN fhe module manufaclurer SHALL documenl fhe configuralion assumplions lhal allow fhe module lo 
meel fhe conducted emissions specificalions. 


B.8.6.2 CONDUCTED SUSCEPTIBIUITY 

RULE B.8.12: 

Each module SHALL operate as specified when subjecled lo conducted noise vollage levels specified in 
Figure B.43 on all power supply volfages used. For lesl mefhod see B.8.7.4. Vmi is fhe Induced Ripple/Noise 
value specified in Table B.7. Vml is the DC Load Ripple/Noise value specified in Table B.7. 

RECOMMENDATION B.8.5: 

Module Eleclroslalic Discharge (ESD) relum palh lo chassis ground should be Ihrough fhe faceplate. The 
faceplate chassis ground is fhe primary relum palh and energy lo any bus pin should be al such a level as lo nol 
interfere wilh normal operalion of mainframe or module e.g. change of slate of dala lines elc. 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 



Section B: VXIbus Implementation of VMEbus Specs 


Page 97 



Figure B.42. Module Conducted Emissions 



Figure B.43. Module Susceptibility Level 
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B.8.6.3 RADIATED EMISSIONS 

Mainframe and modules will specify conformance to chosen standards appropriate to the intended market, e.g. 
FCC, VDE or MIL Spec, for far field radiated emissions. Each module should not contribute more than its fair 
share of the total allowable radiation, i.e. in a thirteen module mainframe, it should not contribute more than 
1/13 of the allowable radiation if its radiation is coherent. Module to module interference is a close-field 
radiation problem. The term close-field is used fo indicate fhose fields wifhin a few centimeters of fhe surface 
of fhe modules. 

RULE B.8.13: 

The module manufaclurer SHALL specify under whaf condifions fhe mainframe confaining fhe module will 
meef fhe chosen radiated emission requiremenfs. 

RECOMMENDATION B.8.6: 

Twelve identical single slof modules plus fhe Slof 0 module should slay wifhin fhe chosen limils of fhe 
mainframe regulalory requiremenl. This is a coherency lesl. 

OBSERVATION B.8.6: 

If one module is tested alone fhe radiation per slof should be 1/13 of fhe allowable far field specification if fhe 
radiation is coherenl. Module radiation allowed is proportional lo fhe number of slols occupied. 

OBSERVATION B.8.7: 

If fhe module complies wilh fhe coherency lesl described in fhe above recommendation Ihen fhe module 
manufaclurer may jusl claim compliance lo fhe regulalory radiation requiremenl wilh no additional 
documenlalion. If Ihe module does nol comply wilh Ihe coherency lesl Ihen Ihe burden is on Ihe module 
manufaclurer lo documenl under whal configurations Ihe mainframe conlaining Ihe module will meel Ihe 
regulalory radiation requirement. 



Figure B.44. A- & B-size Maximum close-field emissions (dB above 1 picolesla) 
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Figure B.45. C- & D-size Maximum close-field emissions (dB above 1 picotesla) 


RULE B.8.14: 

The close-field magnetic emissions of A-size and B-size modules when measured on the intermodule 
separation plane identified by fhe shaded area of Figure B.48 SHALL NOT exceed fhe limif as shown in 
Figure B.44. For fesf mefhod see Secfion B.8.7.5, "Close-Field Magnefic Emissions Tesf". 

RULE B.8.15: 

The close-field magnefic emissions of C-size and D-size modules when measured on fhe intermodule 
separafion plane idenlified by fhe shaded area of Figure B.49 SHALL NOT exceed fhe limif as shown in 
Figure B.45. For fesf mefhod see Secfion B.8.7.5, "Close-Field Magnefic Emissions Tesf". 

RULE B.8.16: 

IF an A-size or B-size module is inserted in a C-size or D-size mainframe, 

THEN fhe close-field magnefic emissions when measured on fhe C-size or D-size infermodule separafion 
plane idenlified by fhe shaded area of Figure B.50 SHALL NOT exceed fhe limif as shown in Figure B.44. 
For tesf mefhod see Secfion B.8.7.5, "Close-Field Magnetic Emissions Tesf". 

RULE B.8.17: 

IF an A-size or B-size module is inserted in a C-size or D-size mainframe, 

THEN fhe close-field magnefic emissions when measured on fhe C-size or D-size infermodule separation 
plane identified by fhe shaded area of Figure B.51 SHALL NOT exceed fhe limif as shown in Figure B.45. 
For tesf mefhod see Section B.8.7.5, "Close-Field Magnetic Emissions Tesf". 

PERMISSION B.8.1: 

A-size and B-size modules MAY use fhe shield of an adapter lo meel fhe close-field magnetic emissions limif 
when inslalled info a C-size or D-size mainframe. 
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RECOMMENDATION B.8.7: 

The A-size and B-size module manufacturer should document the available adapter(s) or procedure(s) that 
allow a module to meet the close-field magnetic compatibility limits when installed into a C-size or D-size 
mainframe. 

OBSERVATION B.8.8: 

The integration of A-size VXI, B-size VXI or standard VME modules into C-size or D-size mainframes will 
require some forethought and planning. The system integrator should carefully consider adapter choice as well 
as module placement to preserve electromagnetic compatibility. 

OBSERVATION B.8.9: 

Eor modules without covers or shields, the surface for close-field testing is defined as fhe infermodule 
separafion plane. The close-field magnefic emissions and suscepfibilify of fhe backplane is nol specified. 

RECOMMENDATION B.8.8: 

Place all significanl sources of radiated emissions, such as swifching power converters or crysfal oscillators, 
wifhin an area 15 cm (6 inches) or less from fhe backplane connectors. Place all radiated emissions sources as 
close as possible to fhe backplane connectors and as far as possible from fhe board guides. 

OBSERVATION B.8.10: 

There is no close field EMC specification for backplanes. Module EMC requiremenfs sfarf 38 mm (1.5 inches) 
from fhe backplane surface. The connector shield described in fhe Mechanical Specification may be required 
fo comply wifh fhe close field magnetic emission specification. 

RECOMMENDATION B.8.9: 

All C-size and D-size backplanes should provide a conductive surface in fhe grounding area described in fhe 
Mechanical Specification. 

OBSERVATION B.8.11: 

There are no specified limifs for broadband or non-repefifive close-field emissions. 

RECOMMENDATION B.8.10: 

Place all significanl sources of broadband emissions as close as possible to fhe backplane connectors and as far 
as possible from fhe board guides. 


B.8.6.4 RADIATED SUSCEPTIBILITY 

Module lo module interference is a close-field suscepfibilify problem. The lerm close-field is used to indicate 
Ihose fields wifhin a few cenlimelers of fhe surface of fhe modules. Close-field magnetic emissions and 
susceplibilily levels should be mel using good engineering design practices. 

RULE B.8.18: 

A-size and B-size modules SHALL operate as specified when subjected to magnetic fields of fhe level shown 
in Eigure B.46 in fhe region of fhe intermodule separation plane identified by fhe shaded area of Eigure B.48. 
Eor lesl melhod see Section B.8.7.6, "Close-Eield Magnetic Suscepfibilify Tesf". 

RULE B.8.19: 

C-size and D-size modules SHALL operate as specified when subjected to magnetic fields of fhe level shown 
in Eigure B.46 in fhe region of fhe intermodule separation plane identified by fhe shaded area of Eigure B.50. 
Eor tesf melhod see Section B.8.7.6, "Close-Eield Magnetic Suscepfibilify Tesf". 

RULE B.8.20: 

C-size and D-size modules SHALL operate as specified when subjected to magnetic fields of fhe level shown 
in Eigure B.47 in fhe region of fhe intermodule separation plane identified by fhe shaded area of Eigure B.51. 
Eor tesf melhod see Section B.8.7.6, "Close-Eield Magnetic Suscepfibilify Tesf". 
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Figure B.46. A- & D-size Minimum close-field susceptibility (dB above 1 picotesla) 



Figure B.47. C- & D-size Minimum close-field susceptibility (dB above 1 picotesla) 
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RECOMMENDATION B.8.11: 

Place all circuits susceptible to radiated emissions, such as front end input circuits, in the area of a module 
greater than 15 cm (6 inches) from the backplane connectors. Place these circuits as close as possible to the 
front face plate and as far as possible from the board guides. 

OBSERVATION B.8.12: 

There are no specified limits for broadband or non-repetitive close field susceptibility. 

RECOMMENDATION B.8.12: 

Place all circuits susceptible to broadband or non-repetitive emissions as close as possible to the front face 
plate and as far as possible from the board guides. 

RECOMMENDATION B.8.13: 

Electric close-fields should be evaluated on all unshielded modules. 

OBSERVATION B.8.13: 

Electric field emissions are easily contained through shielding techniques i.e. Earaday shields. Unshielded 
modules should be checked for excessive electric field emissions, particularly af areas where high volfage 
swings are presenf. A lengfh of coax wifh one or fwo inches of outer conductor shipped back af fhe tip is a 
useful close-field probe for making relafive elechic field measuremenfs. A shield around fhe generating 
module, around fhe suscepfible module or befween fhe modules will usually eliminate any elechic field 
interference problems. 
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B.8.7 Suggested Test Methods 

The test methods described in this section are provided as suggestions to the manufacturers of VXIbus 
mainframes and modules. 

In the following sections, it is assumed that all measurements which are made using a spectrum analyzer, are 
for single-frequency stationary signals. Therefore, the bandwidth and sweep rate must be chosen to accurately 
measure only one frequency component at a time. For modules or mainframes which may generate non- 
stationary signals, for example, swept signals or transients, the specified techniques cannot be used, but the 
manufacturer should point out in his documentation what limitations, if any, may arise because of these 
signals. 

At higher frequencies, a relatively narrow bandwidth may be necessary to obtain sufficient sensitivity. 

Note that all induced and conducted tests are based on peak-to-peak measurements, while the radiated tests are 
based on RMS measurements. 


B.8.7.1 DC LOAD RIPPLE/NOISE TEST OF MAINFRAMES 

The DC load ripple/noise is the maximum periodic and random deviations (PARD) in a power supply voltage 
under a constant DC load, as used within the power supply industry. Using an oscilloscope with a 10 MHz 
bandwidth, measure the peak-to-peak AC voltage on each power supply output while varying the DC load 
from 0 to the mainframe peak current (Imp)- The highest value measured is the DC load ripple/noise. The 
probe should be connected to the backplane using good RF techniques, i.e. using very short leads. 


B.8.7.2 INDUCED RIPPLE/NOISE TEST OF MAINFRAMES 

The Induced Ripple/Noise test requires applying a load of the magnitude and frequencies shown by the Max. 
Rated Mainframe Dynamic Output Current in Figure B.40 while monitoring the power supply voltage to 
guarantee that the total induced and DC load ripple voltage does not exceed that of Figure B.41. 

Set the DC load on the power supply to be half of the rated current (1/2 Imp). For the low frequency tests (up 
to 10 kHz), drive an active load with a low frequency oscillator to the levels specified. Measure the noise 
voltage present at an adjacent slot using an oscilloscope. The total induced and DC load ripple/noise is the 
peak-to-peak value of the AC component. For the higher frequency conducted emission tests, drive a load 
from a tracking oscillator while monitoring the induced voltage at an adjacent slot with a spectrum analyzer. 


B.8.7.3 CONDUCTED EMISSIONS TEST OF MODULES 

The testing of a module's dynamic current should exclude all effects of the mainframe. Because the mainframe 
provides current for backplane terminations, clocks and other devices requiring dynamic current, voltage ripple 
may exist on power pins at various frequencies. This power supply ripple voltage may cause an apparent 
dynamic current flow into the module that is not caused by any current requirements of the module and should 
not be included as part of the module's dynamic current. By supplying voltages to the module under test from 
independent power supplies, the mainframe ripple performance will be isolated from the module dynamic 
current requirements. 

The module being tested should be operating at its worst case current versus frequency requirements. 

A current sensor in series with each supply of the module is used to measure the AC portion of the power 
supply load. Check with an oscilloscope that the module meets the low frequency (up to 10 kHz) conducted 
emissions requirements. A Spectrum Analyzer is used to measure the higher frequency content of the current. 
The module is exercised to find the highest readings. 
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This test should be conducted using a backplane having an impedance of less than 0.2 X Vs / Is in parallel with 
a >0.1 //F bypass capacitor at the measured slot, where Vs is the Module Susceptibility voltage level (Figure 
B.43) and Is is the Module Conducted current level (Figure B.42). 


B.8.7.4 CONDUCTED SUSCEPTIBILITY TEST OF MODULES 

Induce a voltage between each backplane power supply and module at the maximum voltage shown in 
Figure B.41 as measured from the module supply pin to ground. Search for potential frequencies where 
performance is degraded due to the presence of injected noise. For low frequency testing, use a series resistor 
driven by an active load to induce the specified voltage level. For higher frequencies use current probes 
appropriate to the frequency range being tested. Be sure the current probe is rated for the DC current being 
supplied to the module. 


B.8.7.5 CLOSE-FIELD MAGNETIC EMISSIONS TEST 

The equipment to measure the close-field magnetic emissions of a module is a close-field magnetic probe and a 
spectrum analyzer that operates over the frequency range specified in Figure B.44 or Figure B.45. To cover 
fhe frequency range, differenf probes and specfrum analyzers may be required. If is required fhaf fhe close- 
field probes have calibrated antenna factors and fhaf fhe magnefic loop be wifhin 5 mm of fhe end of fhe probe. 
Wifh fhe close-field magnefic probe connected fo fhe specfrum analyzer, move fhe probe lip over fhe enlire 
module surface to search for polenlial radiating spols such as seams and holes. Al all areas where magnetic 
radiation is detected, fhe probe should be oriented to maximize fhe probe oulpul as displayed on fhe specfrum 
analyzer. Using fhe antenna factors of fhe close-field probe, calculate fhe magnetic flux density for each 
frequency of radiation detected. Flux densily levels may nol exceed fhe levels of fhe appropriate figure. 


B.8.7.6 CLOSE-FIELD MAGNETIC SUSCEPTIBILITY TEST 

The equipmenl to lesl fhe susceptibility of a module consisls of a close-field magnefic probe connecled to a 
signal generalor fhaf operates over fhe frequency range specified in Figure B.46 or Figure B.47. To cover fhe 
frequency range, differenf probes and signal generators may be required. If is required fhaf fhe close-field 
probes have calibrated antenna factors and fhaf fhe magnetic loop be wifhin 5 mm of fhe end of fhe probe. 
Connecf fhe close-field magnetic probe to fhe signal generator. For each frequency fesfed, sef fhe signal 
generalor to produce a magnetic flux density al fhe limil given by fhe appropriate figure for fhaf frequency. 
Move fhe probe tip over fhe enlire module surface lo search for polenlial spols where fhe performance of fhe 
module is degraded due to fhe presence of a magnetic field. The probe lip should be wifhin 1 cm of fhe surface 
of fhe module. 


B.8.7.7 EXAMPLES OF CLOSE FIELD MAGNETIC PROBES 

Examples of close-field probes fhaf meel fhe above requiremenls are: 

Magnelek Pari Number 1846 for frequencies from 20 Hz lo 10 kHz 
Hewlett-Packard Model 11941 for frequencies from 10 kHz lo 30 MHz 
Hewlett-Packard Model 11940 for frequencies from 30 MHz to 1 GHz 
EMCO Model 7405 Near-Field Probe Sef may also be used to complemenl fhe above probes. 
An amplifier may be needed wifh any probe to compensale for large probe antenna factors. 

B.9 Reserved 
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B.ll 2eVME Protocol 


B.11.1 Introduction 

The original VMEbus system used the master-slave architecture and an asynchronous handshake scheme. 
Multiple master and slave modules can reside in the same backplane. Both the master module and the slave 
module can transmit data, but the master controls the direction of data transfer. A system controller assigns 
control of the bus to the master. The maximum bandwidth was up to 40 Mbyte/s on a 32-bit data line. The 
VMEbus has evolved to meet the demand of higher-bandwidth data transfer with the introduction of VME64 
and VME64x, which includes 2eVME. 

In 1989, the VME64 protocol was introduced, which extended the throughput to 80-Mbyte/s. This 
improvement was made possible by multiplexing 32-bit address lines into a 64-bit data transfer. Since VME64 
is a handshake protocol, it requires control signals, which are data strobe from the master (DS) and data 
acknowledge from the slave (DTACK). The master asserts DS low to let the slave know that data is valid. The 
slave acknowledges by asserting DTACK low. An additional handshake between DS and DTACK completes 
the single data transfer. This 4-edge handshake requires four delays through the driver, backplane, and the 
receiver, including the settling time of the backplane. The specified delay is dependent upon the number of 
backplane slots and the number of modules occupying those slots. 

The 2eVME (Two Edge VME) protocol allows for the addition of important features to the VXIbus 
architecture: 

1. Theoretical doubling of the peak block data rate to 160 MB/s 

2. Master and Slave terminated 2eVME block Transfers 

3. Reduced number of Address Modes 

Chapter 11 of the VME64x specification, ANSEVITA 1.1-1997 (R2003), details the operation of 2eVME. 
Where VME64 uses a four-edge handshake to transfer data on the backplane, 2eVME uses a two-edge 
handshake to transfer the same amount of data and increases the maximum data transfer from 80MB/s to a 
theoretical limit of 160 MB/s. In effect, it can transfer data at both edges of the control signals DS and 
DTACK. Even though the throughput is doubled, the bandwidth is limited by the fact that it still must wait for 
an acknowledgment from the receiver to complete a data cycle. 

2eVME transfers always use the largest data size available for transfers. Eor a Size C module, transfers are 
done using A32/D64 and A64/D64 accesses. VME64x adds extensions to the address modifiers used on the 
bus, called XAM codes and these control the type of transfer performed. 

OBSERVATION B.11.1: 

2eVME slave modules can be added to a chassis containing standard VXIbus slaves. The controller will be 
able to switch between protocol modes on the backplane and allow interoperation of both types of slaves in a 
system. 

RULE B.11.1: 

During a 2eVME transaction, a VXIbus SLAVE SHALL toggle DTACK* for an address or data phase within 
75 ns after a data strobe (DSO* or DSl*) toggles. 

RULE B.11.2: 
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During a 2eVME transaction, a VXIbus MASTER SHALL toggle the appropriate data strobe (DSO* or DSl*) 
for the next address or data phase within 55 ns after seeing a DTACK* response from a slave. 

OBSERVATION B.11.2: 

The performance of the VXIbus using 2eVME is determined by the signal timing of the master and the slave 
combined. The above two rules set a maximum “system time” for a 2eVME access of 75 ns + 55 ns = 130 ns. 
This means that the minimum 2eVME data transfer rate is defined as ‘8 bytes per access’ / ‘130 ns per access’ 
= 61.5 Mbytes/s. Note that in this observation; the term “access” refers to one half of a 2eVME cycle (i.e. a 
rising or falling edge of the appropriate signal). Note that a greater performance burden is imposed on master 
devices to allow for slaves to be implemented in as economical a manner as possible. 

RECOMMENDATION B.11.1: 

Eor the highest performance in a 2eVME system, VXIbus MASTERS and SLAVES should respond to 
appropriate signal changes as fast a possible. 

B.11.2 Transceivers and Connectors 

Rule 11.1 and 11.2 of the VME64 extensions, ANSEVITA 1.1-1997 (R2003), requires monotonic rising and 
falling edges of the bus signals through the threshold region of the receiver for 2eVME transfers. 

RECOMMENDATION B.11.2: 

SN74VMEH22501 transceivers or an equivalent part should be used in 2eVME designs. These parts are noted 
in the footnote associated with Rule 3.1 of VITA 1.5 (R2003). 

OBSERVATION B.11.3: 

The VITA 2 specification has not been ratified by VITA, but there are several parts that conform to the non- 
ratified specification. These include the SN74BTE16245, the SN74ABTE16246 and the SN74VMEH22501 
and their equivalents. 

RECOMMENDATION B.11.3: 

The stub length from the SN74VMEH22501 to the connector should be as short as possible. To 
reduce system skew, stub lengths should be matched for all the data and control bits. 

RECOMMENDATION B.11.4: 

Using multiple bypass capacitors to stabilize the supply line is also recommended. To reduce high-frequency 
noise, a small capacitor (0.1 pF, or less) for every two VCC pins on the VXIbus side of the SN74VMEH22501 
is recommended. The capacitors should be as close as possible to the VCC pins. An additional large capacitor 
close to the chip helps maintain the dc level of the power-supply line. 
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B.12 2eSST Protocol 

B.12.1 Introduction 


Traditional VMEbus transfers utilize a handshake protocol whereby data strobe (DS) is acknowledged (DTACK). 
Once DTACK is de-asserted, a new cycle can begin. The VME64 protocol requires four delays, and the 2eVME 
requires two delays through the drivers, backplane and receivers plus the settling time of the backplane. (See Section 
B.l 1, 2eVME Protocol, for more details of the various asynchronous handshake modes). 

The 2eSST (Two Edge Source Synchronous Transfer ) protocol still uses the data strobe (DS) to send data, but there 
is no wait for acknowledgment (DTACK). Therefore, data can be streamed at much higher rates. The transfer rate of 
the system is not determined by the propagation delay from source to destination but by skew, the variation in 
propagation delay through the drivers, backplane and receivers. The transfer rate of the source synchronous protocol 
is determined by how precisely skew can be controlled in the system. 

Chapter 2 of the VME64 specification extension, ANSEVITA 1.5 (R2003), details the operation of 2eSST. The 
2eSST protocol has been added to enhance the performance of the VXIbus. The 2eSST protocol defines three new 
transfer rates for the VXIbus based on the source synchronous transfer technology. The new transfer rates are 160 
MB/s, 267 MB/s and 320 MB/s. The VITA standard 2eSST protocol also provides for broadcast data transfers; 
however, this is not supported in the VXIbus standard. Being defined as an additional transfer protocol, VXIbus 
modules implementing the 2eSST protocol will be fully backwards compatible for accesses using standard methods. 


OBSERVATION B.12.1: 

2eSST slave modules can be added to a chassis containing standard VXIbus slaves. The controller will be able 
to switch between protocol modes on the backplane and allow interoperation of both types of slaves in a 
system. 

RECOMMENDATION B.12.1: 

Eor the highest performance in a 2eSST system, VXIbus MASTERS and SLAVES should respond to 
appropriate signal changes as fast a possible. 


B.12.3 Transceivers and Connectors 

Rules 3.1 and 3.2 of the VME64 extension specification on 2eSST, ANSIA^ITA 1.5 (R2003), requires monotonic 
rising and falling edges of the bus signals through the threshold region of the receiver for 2eSST transfers. 

RECOMMENDATION B.l 2.2: 

SN74VMEH22501 transceivers or an equivalent part should be used in 2eSST designs. These parts are noted 
in the footnote associated with rule 3.1 of VITA 1.5-2003. 

OBSERVATION B.12.3: 

The VITA 2 specification has not been ratified by VITA, buf fhere are several parfs fhaf conform fo fhe non- 
ralified specificalion. These include fhe SN74BTE16245, fhe SN74ABTE16246 and fhe SN74VMEH22501 
and fheir equivalenfs. 

RECOMMENDATION B.12.3: 

The sfub lengfh from fhe SN74VMEH22501 fo fhe connector should be as short as possible. To 
reduce system skew, sfub lengfhs should be mafched for all fhe dafa and confrol bifs. 
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RECOMMENDATION B.12.4: 

Using multiple bypass capacitors to stabilize the supply line also is recommended. To reduce high-frequency 
noise, a small capacitor (0.1 pF, or less) for every two VCC pins on the VXIbus side of the SN74VMEH2250I 
is recommended. The capacitors should be as close as possible to the VCC pins. An additional large capacitor 
close to the chip helps maintain the dc level of the power-supply line. 
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B.13 VXS Support in VXIbus 

B.13.1 Introduction to VXS 

The VME Switched Serial (VXS) standard defines the physical features that enable high-speed serial 
communication. VXS defines a high-speed connector in the PO/JO position between PI and P2, and it defines 
alignment and keying features which can be used to protect modules from connecting to different serial fabric 
technologies (optional in this specification). This specification refers to and follows closely the specifications 
required and outlined in the VXS standards ANSEVITA 41.0-2006 and the Gigabit Ethernet Control Channel 
on VXS (VITA 41.6). Refer to those standards for additional information. VITA 41.0 defines fhe 
infrasfrucfure on which is assigned IX GigE links for communicafion over signal sefs currenfly defined as 
reserved for fulure use in fhaf standard. VITA 41.6 provides fhe guidelines for fhe use of GigE links, GigE 
sysfem managemenf, and GigE swifching services and managemenf. 

VXS defines fwo fypes of cards: fhe payload card and fhe swifch card. The payload card fils fhe MulliGig RT2 
connector belween fhe existing PI and P2 connectors, in fhe position designated PO. VXS backplanes have one 
mating MulliGig RT2 (JO) connector for each payload card slol. Bolh PO and JO connector positions are 
illuslraled in Eigure B.19, defined earlier in Ihis slandard. 

Payload cards can conned belween each olher Ihrough fhe swifch card. Signals from each PO connector on a 
payload card are routed Ihrough fhe backplane Iraces to fhe swifch card. The swifch card acls as a router to 
conned signals from one payload card to anolher. The swifch module can supporl literally any serial protocol 
if implemented wilh mechanical switehes. 


4X serial data olane 



Figure B.52 VXS Payload Card Communication 


Eigure B.52 illuslrales an example implemenlalion of fhe swifch card inlerconned to payload cards in a 
VMEbus mainframe. Up to fwo swifch modules can be inslalled in Ihis particular implemenlalion, providing 
redundancy of signal palhs. This is furlher illuslraled in Eigure B.53 where swifch cards mounted in fhe center 
of fhe mainframe have minimized fhe signal palh belween modules and fhe swifch. This also provides 
addilional swifch card signal palhs for increased flexibility in fhe sysfem. 
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Figure B.53 Example implementation of switch modules in a VMEbus mainframe 


B.13.2 VXS in VXIbus 

In a VXIbus mainframe, the payload card would be referred to as a VXIbus module or simply module. It is the 
intent of the VXIbus specification to recommend existing VXS switch cards to be used to route signals 
between modules equipped with the PO connector. Therefore, the terminology for switch card will remain. 

The VXIbus is oriented towards test systems and does not require redundancy of signal paths. Therefore, the 
VXIbus specification recommends either a single switch module or no switch module, but it does not preclude 
the use of multiple switch cards in a VXIbus system. VXIbus recommends mounting the switch card behind 
the Slot 0 module to avoid using slots needed for instrument modules. This is also necessary since most 
VXIbus mainframes utilize the area behind the backplane for power supplies. 

Eigure B.54 illustrates the recommended configuration for implementing VXS within a VXIbus mainframe. A 
VITA 41.0 compliant switch card would plug into the rear slot of the VXIbus mainframe info fhe 
J1/J2/J3/J4/J5 connectors. Each JO connector on fhe backplane routes signals from module serial fabric 
channels to fhe swilch card for roufing. The number of slofs supporting VXS would be limited to 10 due to 
signal pafh lengfh and limited availability of pins for roufing in fhe swifch card. 
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Legend 
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Figure B.54 Illustration of the Recommended VXI-VXS backplane 

An implementation using no switch card would allow dedicated or configurable connections between JO 
connectors such that VXIbus modules could directly communicate with each other without a switch. This 
could be similar to the implementation of the VXI local bus with appropriate key locks that would only permit 
certain modules to be positioned next to each other. There are system management resources provided through 
I^C signal paths that can also provide control of the signal path interconnect. More information on the no¬ 
switch module implementation can be found in VITA 38 System Management for VME. 

The AO/KO alignment and key locking provide the necessary mechanism to permit only certain modules to be 
plugged into particular slots. The backplane can be configured for any particular type of VXS module, which 
has its keying defined in the VITA 41.0 specification. However, this specification currently only defines the 
use of the VITA 41.6 Gigabit Ethernet Control Channel. Therefore, keying has been made optional in this 
current specification. 
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B.13.3 VXS Modules 

Mechanically, the VXI payload module uses a keying module, PO connector, and alignment mechanism, as 
illustrated in Figure B.55. The VXS oriented VXIbus module is required to have the PI connector in order to 
provide power and permit the VXIbus resource manager to configure the address space used by the module. 
The P2 connector provides additional resources such as a variety of power supply lines and synchronization 
signals between modules in a VXIbus frame. PO pin connections and connector are specified in Section B.6.4 
of this standard. PI and P2 connectors are specified in Section B.6.I and B.6.2. Figure B.I9 specifies the 
orientation of connectors, including PO, AO, and KO. 



Figure B.55. VXI Module showing VXS PO, AO alignment, and KO keying mechanism 


B.13.4 VXS Switch Card 

Switch will provided point-to-point connections to VXS modules and allow all or a subset of the VXS modules 
connected to it to intercommunicate. A switch card used in a VXIbus environment is expected to be the same 
switch card used in a VMFbus environment. A typical switch card is illustrated in Figure B.56. It includes 
connectors P1-P5, where P2-P5 provide communication paths for high speed signals, and PI provides lower 
speed signals typically used for communication between the switch module and the mainframe. The switch 
card also includes a power connector. 
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Figure B.56. VXS Switch Card 


RECOMMENDATION B.13.1: 

It is recommended that the VXIbus mainframe support zero or one switch card. 

PERMISSION B.13.1: 

A VXIbus mainframe MAY support two switch cards. 

RULE B.13.1: 

Switch modules used in VXIbus SHALL incorporate the connectors and pin definitions specified in Sections 
4.3 through 4.7 of the VITA 41.0 base standard. 


B.13.5 Alignment and Keying 

The alignment and keying mechanisms for VXS modules, switch modules, and backplane are defined and 
specified in the VITA 41.0 base standard. VITA 41.6 specifies modules builf according to fhaf standard. 

PERMISSION B.13.2: 

The VXIbus backplane MAY incorporate fhe AO and KO key as defined in VITA 41.0 for module slofs. 

PERMISSION B.13.3: 

The VXIbus backplane MAY incorporate fhe A1 and K1 key and A2 and K2 key as defined in VITA 41.0 for 
swifch slofs. 
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B.13.6 Signal Routing and Pin Assignments 

All transmit and receive signals are named with respect to the board on which they are defined. Therefore, 
VITA 41.6 backplanes implementing slot-to-slot links route TX pairs on one end of the link to the 
corresponding RX pairs on the other end (and vice versa). 

The PO/JO pin definitions and connectors are defined in Section B.6.4 and illustrated in Figure B.15 and Figure 
B.19 of this standard. Signal assignments adhere to the VITA 41.6 standard for those connectors. Figure B.57 
and Figure B.58 provide detailed dimensions of the backplane VXS module connector and VXS switch card 
connectors for the VXIbus backplane. Figures B.59 to B62 define the routing signals for connectors J2, J3, J4, 
and J5 of the switch card slot according to the VITA 41.6 standard. 

The VXS JO connector supports the following functions: 

• Fabric A - 2.4 Gbs channel consisting of 4 hi-directional links each link consisting of 2 
differential pairs. 

• Fabric B - 2.4 Ghs channel consisting of 4 hi-directional links each link consisting of 2 
differential pairs. 

• Control Plane A - IG BASF KX Fthernet channel consisting of two differential pairs (PA_TX-(-/- 
0-3 and PA_RX-h/- 0-3). 

• Control Plane B - IG BASF KX Fthernet channel consisting of two differential pairs 
(PBA_TX-h/- 0-3 and PBA_RX-h/- 0-3). 

• IPMB-A I2C System Management Bus per ANSI-VITA 38 2003 (PICMG 2.9) consisting of a 
Serial Clock (PA_SCL) and Serial Data (PA_SDA) 

• IPMB-B I2C System Management Bus per ANSI-VITA 38 2003 (PICMG 2.9) consisting of a 
Serial Clock (PB_SCL) and Serial Data (PB_SDA) 

RULE B.13.2: 

Connectors and pin definitions for module PO/JO and switch slot J2-J5 connectors SHALL adhere to Section 
5.2 of the VITA 41.6 base standard. 

PERMISSION 13.4: 

The mainframe vendor MAY choose to make VXS module and switch slots optional. 

B.13.7 System Management of VXS Modules and Switch Card 

The fundamental approach to system management recommended is the use of Intelligent Platform 
Management Interface (IPMI). The physical connections are the Intelligent Platform Management Bus or 
IPMB on I2C routed from one or more switch slots to the VXS module slots. The VITA-41 standard defines 
the PA_SCL, PA_SDA, PB_SCL, and PB_SDA signals in Table 6.4 of the VITA-41 standard. These signals 
are also defined in P2 of the VXIbus standard for management of system resources. 

PERMISSION 13.5: 

The mainframe vendor MAY use the IPMI approach with I^C to control VXS switch cards and modules. 

RULE B.13.3: 

Module and switch control ports SHALL adhere to Sections 5.3 of VITA 41.6 

PERMISSION 13.6: 

Note that the PxSDA, PxSCF signals in J1 are optional and are only required when implementing system 
management. 
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Figure B.57 Backplane VXS module connector positioning 
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Figure B.58 Backplane VXS switch card connector positioning 
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Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

Row I 

1 

PP17 RX0+ 

PP17 RX0- 

GND 

PP17 TX0- 

PP17 TX0- 

GXD 

RFU 

RFU 

GXD 

2 

GNT) 

PP17 RX1+ 

PP17 RX1- 

GND 

PP17 TX1* 

PP17 TX1- 

GND 

RFU 

RFU 

3 

PP17 RX2+ 

PP17 RX2- 

GND 

PP17 TX2- 

PP17 TX2- 

GXD 

RFU 

RFU 

GXD 

4 

GXD 

PP17 RX3* 

PP17 RX3- 

GND 

PP17 TX3- 

PP17 TX3- 

GND 

RFU 

RFU 

5 

PP15 RX0+ 

PP15 RX0- 

GND 

PP15 TX0- 

PP15 TX0- 

GXD 

RFU 

RFU 

GXD 

6 

GXT) 

PP15 RX1- 

PP15 RX1- 

GND 

PP15 TX1- 

PP15 TX1- 

GND 

RFU 

RFU 

7 

PP15 RX2+ 

PP15 RX2- 

GND 

PP15 TX2- 

PP15 TX2- 

GXD 

RFU 

RFU 

GXD 

8 

GXD 

PP15 RX3- 

PP15 RX3- 

GND 

PP15 TX3- 

PP15 TX3- 

GND 

RFU 

RFU 

9 

PP13 RX0+ 

PP13 RX0- 

GND 

PP13 TX0- 

PP13 TX0- 

GXD 

SP3 TX0- 

SP3 TX0- 

GXD 

10 

GXD 

PP13 RX1+ 

PP13 RX1- 

GND 

PP13 TX1- 

PP13 TX1- 

GND 

SP3 TX1- 

SP3 TX1- 

11 

PP13 RX2+ 

PP13 RX2- 

GND 

PP13 TX2- 

PP13 TX2- 

GXD 

SP3 TX2- 

SP3 TX2- 

GXD 

12 

GXD 

PP13 RX3* 

PP13 RX3- 

GND 

PP13 TX3- 

PP13 TX3- 

GND 

SP3 TX3- 

SP3 TX3- 

13 

PP11 RX0+ 

PP11 RX0- 

GND 

PP11 TX0- 

PP11 TX0- 

GXD 

SP3 RX0+ 

SP3 RX0- 

GXD 

14 

GXD 

PP11 RX1- 

PP11 RX1- 

GND 

PP11 TX1- 

PP11 TX1- 

GND 

SP3 RX1+ 

SP3 RX1- 

15 

PPll RX2+ 

PPll RX2- 

GND 

PPll TX2- 

PPll TX2- 

GXD 

SP3 RX2+ 

SP3 RX2- 

GXD 

16 

GXD 

PP11_RX3- 

PP11_RX3- 

GND 

PP11_TX3- 

PP11_TX3- 

GND 

SP3_RX3+ 

SP3_RX3- 


Figure B.59 Backplane Switch Slot J5 Signal Assignments 



Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

Row I 

1 

PP9 RXO- 

PP9 RXO- 

GND 

PP9 TXO- 

PP9 TXO- 

GXD 

PP5 TXO- 

PP5 TXO- 

GXD 

2 

GXD 

PP9 RX1- 

PP9 RX1- 

GND 

PP9 TX1+ 

PP9 TX1- 

GND 

PP5 TX1- 

PP5 TX1- 

3 

PP9 RX2- 

PP9 RX2- 

GND 

PP9 TX2- 

PP9 TX2- 

GXD 

PP5 TX2- 

PP5 TX2- 

GXD 

4 

GXD 

PP9 RX3- 

PP9 RX3- 

GND 

PP9 TX3+ 

PP9 TX3- 

GND 

PP5 TX3- 

PP5 TX3- 

5 

PP7 RX0- 

PP7 RX0- 

GND 

PP7 TXO- 

PP7 TX0- 

GXD 

PP5 RX0+ 

PP5 RX0- 

GXD 

6 

GXD 

PP7 RXl- 

PP7 RXl- 

GND 

PP7 TX1+ 

PP7 TXl- 

GND 

PP5 RX1+ 

PP5 RXl- 

7 

PP7 RX2- 

PP7 RX2- 

GND 

PP7 TX2- 

PP7 TX2- 

GXD 

PP5 RX2+ 

PP5 RX2- 

GXD 

8 

GXD 

PP7 RX3- 

PP7 RX3- 

GND 

PP7 TX3+ 

PP7 TX3- 

GND 

PP5 RX3+ 

PP5 RX3- 

9 

PP3 RXO- 

PP3 RXO- 

GND 

PP3 TXO- 

PP3 TXO- 

GXD 

SPl TXO- 

SPl TXO- 

GXD 

10 

GXD 

PP3 RX1- 

PP3 RX1- 

GND 

PP3 TX1+ 

PP3 TX1- 

GND 

SP1 TX1- 

SP1 TX1- 

11 

PP3 RX2- 

PP3 RX2- 

GND 

PP3 TX2- 

PP3 TX2- 

GXD 

SP1 TX2- 

SP1 TX2- 

GXD 

12 

GXD 

PP3 RX3- 

PP3 RX3- 

GND 

PP3 TX3+ 

PP3 TX3- 

GND 

SP1 TX3- 

SP1 TX3- 

13 

PPl RXO- 

PPl RXO- 

GND 

PPl TXO- 

PPl TXO- 

GXD 

SPl RX0+ 

SPl RXO- 

GXD 

14 

GXD 

PP1 RX1- 

PP1 RX1- 

GND 

PP1 TX1+ 

PP1 TX1- 

GND 

SP1 RX1- 

SP1 RX1- 

15 

PP1 RX2- 

PP1 RX2- 

GND 

PP1 TX2- 

PP1 TX2- 

GXD 

SP1 RX2+ 

SP1 RX2- 

GXD 

16 

GXD 

PPl RX3- 

PPl RX3- 

GND 

PPl TX3+ 

PPl TX3- 

GND 

SPl RX3- 

SPl RX3- 


Figure B.60 Backplane Switch Slot J4 Signal Assignments 
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Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

Row I 

1 

PP2 RXO- 

PP2 RXO- 

GND 

PP2 TXO- 

PP2 TXO- 

GXD 

SP2 TXO- 

SP2 TXO- 

GXT) 

2 

GXD 

PP2 RX1- 

PP2 RX1- 

GND 

PP2 TX1+ 

PP2 TX1- 

GND 

SP2 TX1- 

SP2 TX1- 

3 

PP2 RX2- 

PP2 RX2- 

GND 

PP2 TX2- 

PP2 TX2- 

GXD 

SP2 TX2- 

SP2 TX2- 

GXT) 

4 

GXD 

PP2 RX3- 

PP2 RX3- 

GND 

PP2 TX3+ 

PP2 TX3- 

GND 

SP2 TX3- 

SP2 TX3- 

5 

PP4 RX0- 

PP4 RX0- 

GND 

PP4 TX0- 

PP4 TX0- 

GXD 

SP2 RX0+ 

SP2 RX0- 

GXT) 

6 

GXD 

PP4 RX1- 

PP4 RX1- 

GND 

PP4 TX1+ 

PP4 TX1- 

GND 

SP2 RX1+ 

SP2 RX1- 

7 

PP4 RX2- 

PP4 RX2- 

GND 

PP4 TX2- 

PP4 TX2- 

GXD 

SP2 RX2+ 

SP2 RX2- 

GXT) 

8 

GXD 

PP4 RX3- 

PP4 RX3- 

GND 

PP4 TX3+ 

PP4 TX3- 

GND 

SP2 RX3+ 

SP2 RX3- 

9 

PP8 RX0- 

PP8 RX0- 

GND 

PP8 TX0- 

PP8 TX0- 

GXD 

PP6 TX0- 

PP6 TX0- 

GXT) 

10 

GXD 

PP8 RX1- 

PP8 RX1- 

GND 

PP8 TX1+ 

PP8 TX1- 

GND 

PP6 TX1- 

PP6 TX1- 

11 

PP8 RX2- 

PP8 RX2- 

GND 

PP8 TX2- 

PP8 TX2- 

GXD 

PP6 TX2- 

PP6 TX2- 

GXT) 

12 

GXD 

PP8 RX3- 

PP8 RX3- 

GND 

PP8 TX3+ 

PP8 TX3- 

GND 

PP6 TX3- 

PP6 TX3- 

13 

PP10 RX0+ 

PP10 RX0- 

GND 

PP10 TX0- 

PP10 TX0- 

GXT) 

PP6 RX0+ 

PP6 RX0- 

GXT) 

14 

GXT) 

PPIO RXl- 

PPIO RXl- 

GND 

PPIO TXl* 

PPIO TXl- 

GND 

PP6 RX1+ 

PP6 RXl- 

15 

PP10 RX2+ 

PP10 RX2- 

GND 

PP10 TX2- 

PP10 TX2- 

GXT) 

PP6 RX2+ 

PP6 RX2- 

GXT) 

16 

GXD 

PPIO RX3- 

PPIO RX3- 

GND 

PPIO TX3^ 

PPIO TX3- 

GND 

PP6 RX3+ 

PP6 RX3- 


Figure B.61 Backplane Switch Slot J3 Signal Assignments 



Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

Row I 

1 

PP12 RX0+ 

PP12 RX0- 

GXT) 

PP12 TX0- 

PP12 TX0- 

GXT) 

SP4 TX0- 

SP4 TX0- 

GND 

2 

GND 

PP12 RX1+ 

PP12 RX1- 

GXD 

PP12 TX1- 

PP12 TX1- 

GND 

SP4 TX1+ 

SP4 TX1- 

3 

PP12 RX2+ 

PP12 RX2- 

GXT) 

PP12 TX2- 

PP12 TX2- 

GXT) 

SP4 TX2- 

SP4 TX2- 

GND 

4 

GND 

PP12 RX3+ 

PP12 RX3- 

GND 

PP12 TX3- 

PP12 TX3- 

GND 

SP4 TX3+ 

SP4 TX3- 

5 

PP14 RX0+ 

PP14 RX0- 

GXT) 

PP14 TX0- 

PP14 TX0- 

GXT) 

SP4 RX0+ 

SP4 RX0- 

GND 

6 

GND 

PP14 RX1+ 

PP14 RX1- 

GND 

PP14 TX1- 

PP14 TX1- 

GND 

SP4 RX1- 

SP4 RX1- 

7 

PP14 RX2+ 

PP14 RX2- 

GXT) 

PP14 TX2- 

PP14 TX2- 

GXT) 

SP4 RX2+ 

SP4 RX2- 

GND 

8 

GND 

PP14 RX3+ 

PP14 RX3- 

GND 

PP14 TX3- 

PP14 TX3- 

GND 

SP4 RX3- 

SP4 RX3- 

9 

PP16 RX0+ 

PP16 RX0- 

GXT) 

PP16 TX0- 

PP16 TX0- 

GXT) 

S\VC TXO- 

SWC TX0- 

GND 

10 

GND 

PP16 RX1+ 

PP16 RX1- 

GXD 

PP16 TX1- 

PP16 TX1- 

GND 

SWC TX1+ 

SWC TX1- 

11 

PP16 RX2+ 

PP16 RX2- 

GND 

PP16 TX2- 

PP16 TX2- 

GND 

S\VC TX2- 

SWC TX2- 

GND 

12 

GND 

PP16 RX3+ 

PP16 RX3- 

GND 

PP16 TX3- 

PP16 TX3- 

GND 

SWC TX3+ 

SWC TX3- 

13 

PP18 RX0+ 

PP18 RX0- 

GXT) 

PP18 TX0- 

PP18 TX0- 

GXT) 

S\VC RX0+ 

SWC RX0- 

GND 

14 

GND 

PP18 RX1+ 

PP18 RX1- 

GND 

PP18 TX1- 

PP18 TX1- 

GND 

S\VC RX1- 

SWC RX1- 

15 

PP18 RX2+ 

PP18 RX2- 

GXT) 

PP18 TX2- 

PP18 TX2- 

GXT) 

SWC RX2+ 

SWC RX2- 

GND 

16 

GND 

PP18_RX3+ 

PP18_RX3- 

GND 

PP18_TX3- 

PP18_TX3- 

GND 

SWC_RX3- 

SWC_RX3- 


Figure B.62 Backplane Switch Slot J2 Signal Assignments 
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Row A 

Row B 

Row C 

Row D 

Row E 

Row F 

Row G 

Row H 

1 

PEN* 

RFl 

SER.\ 

SERB 

+5 STBY 

ACF.4IL* 

SYSFAIL* 

SYSRST* 

2 

GAO* 

GAl* 

GA2* 

GA3* 

GA4* 

GAP* 

LIT 

RFl' 

3 

S\V SE1 

SW SE2 

SM SE3 

SM SE4 

SW SE5 

SW SE6 

SW SE7 

SW SE8 

4 

SW TX+ 

SW TX- 

SW RX+ 

SW RX- 

RFU 

RFU 

RFU 

RFU 

5 

GND 

GND 

GND 

GND 

GND 

GND 

GND 

GND 

6 

PP17 SGTX- 

PPIT SGTX- 

PP15 SGTX+ 

PP15 SGTX- 

PP17 SGR\+ 

PP17 SGRX 

PP13 SGRX+ 

PP15 SGRX- 

7 

PP9 SGTX+ 

PP9 SGTX- 

PP7 SGTX- 

PP7 SGTX- 

PP9 SGRX+ 

PP9 SGRX- 

PP7 SGRX-h 

PP7 SGRX- 

8 

PP1 SGTX+ 

PP1 SGTX- 

PP2 SGTX- 

PP2 SGTX- 

PP1 SGRX+ 

PP1 SGRX- 

PP2 SGR\+ 

PP2 SGRX- 

9 

PP8 SGTX+ 

PP8 SGTX- 

PP10 SGTX+ 

PP10 SGTX- 

PP8 SGRX+ 

PP8 SGRX- 

PP10 SGRX+ 

PP10 SGR.\- 

10 

PP16 SGTX- 

PP16 SGTX- 

PP18 SGTX+ 

PP18 SGTX- 

PP16 SGRX+ 

PP16 SGRX- 

PP18 SGRX+ 

PP18 SGRX- 

11 

PP13 SGTX- 

PP13 SGTX- 

PP11 SGTX+ 

PP11 SGTX- 

PP13 SGRX+ 

PP13 SGRX- 

PP11 SGRX+ 

PP11 SGRX- 

12 

PP5 SGTX+ 

PP5 SGTX- 

PP3 SGTX- 

PP3 SGTX- 

PP5 SGRX+ 

PP5 SGRX- 

PP3 SGR\+ 

PP3 SGR\- 

13 

PP4 SGTX+ 

PP4 SGTX- 

PP6 SGTX- 

PP6 SGTX- 

PP4 SGRX+ 

PP4 SGRX- 

PP6 SGRX+ 

PP6 SGRX- 

14 

PP12 SGTX- 

PP12 SGTX- 

PP14 SGTX+ 

PP14 SGTX- 

PP12 SGRX+ 

PP12 SGRX- 

PP14 SGRX+ 

PP14 SGRX- 

15 

PB SDA 

PBSCL 

PA SDA 

PA SCL 

RFU 

RFU 

RFU 

RFU 

16 

RFl 

RFl 

RFU 

RFU 

RFU 

RFU 

RFU 

RFl' 


Figure B.63 Backplane Switch Slot J1 Signal Assignments 
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C. SYSTEM ARCHITECTURE 


C.l VXIbus SYSTEM ARCHITECTURE OVERVIEW 

The VXIbus architecture allows a wide range of instruments, interface cards or computers from different 
manufacturers to coexist as modules in the same cardcage. The range of the applications being addressed by 
different cardcages in the VXIbus family is very broad and, hence, the architecture is intentionally left open to 
accommodate this flexibility. VXIbus does not define a specific system hierarchy or topology nor does it 
specify the type of microprocessor, operating system or the type of interface to the host computer. What 
VXIbus defines is a foundation (or platform) upon which the above decisions can be made while ensuring 
compatibility between different manufacturers. Figure C.l shows some of the possible system configurations 
and may help illustrate the flexibility that is allowed by the VXIbus standard. 






Inst#l Inst #2 


Figure C.l. Typical System Configurations 
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As shown by the examples in Figure C.l there are many topologies possible within the VXIbus architecture. 
These include single CPU systems that centralize the intelligence for all their instrument modules, multiple 
CPU systems with distributed intelligence and stand alone mainframes that contain a host computer running 
user applications. Each of these topologies has different communication needs which are met by a layered set 
of communication protocols illustrated in Figure C.2. 


Device 

Specific 

Protocols 


Device 

Specific 

Protocols 


Device 488.2 

Specific Syntax 

Protocols - 


Device 

Specific 

Protocols 


Shared 

Memory 

Protocol 


488-VXIbus 
Protocol 


Word Serial Protocol 


Communication Registers 


Configuration Registers 


Figure C.2. VXIbus Communication Layers 


In order to support automatic system and memory configuration, the VXIbus standard specifies a minimum 
amount of capability on each device regardless of its function. A VXIbus device (see Section C.2, "Device 
Operation"), being the lowest element of a hierarchy, has a set of "Configuration Registers", all totally 
accessible from PI on VMEbus which allow the system to identify the device, its class, model and 
manufacturer, address space (Alb, A24, A32, A64) and memory requirements. VXIbus devices with only this 
minimum level of capability are called REGISTER BASED DEVICES. As an example, the single CPU 
system shown in Figure C.l may implement all of its instruments using only Register Based Devices with 
device specific protocols on how the CPU communicates with each of those instruments. VXIbus also defines 
MEMORY DEVICES, (See Section C.2.3, "Memory Devices") that can be identified as RAM, ROM or other 
memory types and be configured in contiguous blocks of memory based on speed or memory type. 

If a higher level of communication ability between modules is desired in the system, VXIbus defines a class of 
devices called MESSAGE BASED DEVICES. In addition to the configuration registers mentioned above. 
Message Based Devices are required to have communication registers that are accessible to other modules in 
the system. Each device in the system can then use specific communication protocols such as VXIbus's Word 
Serial Protocol (See Section C.3.3.1, "Word Serial Protocols") to communicate with other devices. The 
multi-CPU system shown in Figure C.l is a good example of this type of system where each instrument is a 
Message Based Device and is therefore capable of receiving instructions from a host or a common host 
interface. Note that by agreeing on a class of communication protocols, such as Word Serial, different 
manufacturers can now build any of those instruments and be assured of compatibility with the rest of the 
system. Higher level communication protocols, referred to as Shared Memory Protocols in Figure C.2, can 
later be defined using these platforms. 
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Communication between VXIbus devices is based on a hierarchical device relationship involving 
COMMANDERS and SERVANTS. For many systems, such as the single CPU system shown in Figure C.l, 
only the first level of this hierarchy exists. In that example, the CPU and host interface device is a Commander 
which controls the three instrument Servants. A Commander is able to initiate communication with its 
Servants based on their capabilities. If the Servants are Message Based Devices, such communication can take 
place using COMMANDS which are described by the Word Serial Protocols. Communication with Register 
Based Servants is device dependent and may vary between systems. The Commander/Servant hierarchy can 
be nested since a Message Based Device may be a Commander as well as a Servant to the next level above it. 
The hierarchical instrument system of Figure C.l is an example of such a system. Instrument #I and #2 are 
shown as multi device instruments that have two Servants each while the instruments themselves may be 
Servants to the host interface. 

A common element that instruments may desire to share among them is the interface to the host computer as 
shown in the Multi-CPU system example in Figure C.l. The 488-VXIbus interface device (see Section D.2, 
"488-VXIbus Interface") is an example of such a device. VXIbus defines fhis as a funcfion specific Message 
Based Device wifh communicafion protocols fhaf supporf IEEE-488 functions. This device, if provided, may 
be shared by fhe insfmmenfs needing to be accessed by fhe hosf. Ofher hosf or peripheral interfaces such as 
RS-232, LAN or Human Interfaces can be designed in a similar fashion. 

Regardless of fhe topology of fhe VXIbus cardcage (See Eigure C.I.), VMEbus's multiple bus master 
architeclure demands a minimal amounf of system related funclions fhaf are performed by a cenfral 
RESOURCE MANAGER (see Section C.4.1, "Resource Manager"). The following are some of fhe functions 
a Resource Manager MAY need to perform depending on fhe fopology of fhe sysfem. 

• Address map configuration. To configure fhe A24, A32 and A64 address maps and assign blocks of 
addresses to fhe devices requiring fhem. 

• Determining System Hierarchy. In a multi-CPU sysfem, fhe potential for more fhan one processor to fry 
and confrol anofher device exisfs. The Commander/Servanf hierarchies determined by fhe Resource 
Manager prevenf fhis fype of conflicl. 

• Allocating Shared System Resources. A cenfral Resource Manager (e.g. operafing sysfem) is needed in 
sysfems fhaf share blocks of memory for communication or share ofher hardware resources such as frigger 
busses. 

• Performing System Self Test and Diagnostics. 

• Initialization of all Commanders in the system. 
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C.2 DEVICE OPERATION 


C.2.1 Device Overview 

Devices are the lowest logical component in the VXIbus system. Normally a device will consist of one 
VXIbus module. However, multi-board devices and multi-device boards are permitted. There is a unique 
Logical Address associated with each device in the system. Examples of devices are computers, multimeters, 
multiplexers, oscillators, operator interfaces and counters. VXIbus devices may be categorized by their 
supported protocols into four classes as illustrated in Figure C.3. 

• Message Based Devices support the VXIbus configuration and communication protocols. This category 
includes only devices with Commander and/or command based Servant elements. Examples of Message 
Based Devices are any devices with local intelligence that require a level of communication capability 
such as DMM's, Spectrum Analyzers, Display Controllers, 488-VXIbus interface devices. Switch 
controllers, etc. 

• Register Based Devices support VXIbus register maps, but no VXIbus communication protocols. This 
category is comprised of devices having Register Based Servant elements. Typically Register Based 
Devices are simple, inexpensive devices such as simple switches, digital EO cards, simple serial interface 
cards and in general any card that requires little or no local intelligence. More sophisticated devices could 
also be implemented as Register Based Devices that rely on Message Based Devices for their instructions. 

• Memory Devices have configuration registers and contain certain attributes of a Memory Device such as 
type and access time, etc. but have no other VXIbus defined registers or protocols. Bubble memory, RAM 
and ROM cards are in this category. 

• Extended Devices are special purpose VXIbus devices that have configuration registers so they can be 
identified by the system. This category of devices will allow for definition of future device classes to 
support further levels of compatibility. 

Hybrid Devices are VMEbus compatible devices that know about VXIbus devices and have the ability to 
communicate with them or make use of them, but don't themselves comply with VXIbus device requirements. 
Existing VMEbus boards with the appropriate software to make use of VXIbus devices are an example of this 
class of device. 

Non-VXIbus devices are VMEbus devices that do not comply with or use any of the VXIbus requirements. 

C.2.1.1 DEVICE SLAVE CAPABILITIES 

All VXIbus devices have a common set of VMEbus slave attributes. These include standard memory maps, 
common addressing modes and standard register definitions. 


C.2.1.1.1 Device Addressing 

All VXIbus devices have registers located within 64 byte blocks in the A16 address space. The base address of 
a device's registers is determined by the device's unique Logical Address. The Logical Address selector is an 
eight (8) bit selector which has 256 unique settings. The Logical Address is the value indicated by this selector 
and corresponds to bits 6 —>13 of the device register base address. Bits 14 and 15 of the base address are both 
1 and the base address is: 

Vx64-r49152 

where Vis the device's Logical Address. 
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Figure C.3. Device Classifications 
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If a device requires fewer than 64 bytes of address space, all of it may reside within the defined 64 byte block. 
Otherwise, it has additional registers in the A24, A32 or A64 address space. The base address of a device's 
A24, A32 or A64 registers is programmed via an Offset register in the configuration portion of its A16 
registers. 

RULE C.2.1: 

Every VXIbus device SHALL have a non-volatile means of selecting Logical Addresses and implement the 
defined A16 addressing scheme. 

RULE C.2.2: 

IF a VXIbus device has A24, A32 or A64 registers, 

THEN the base address of such registers SHALL be programmable via its Offset register in its A16 
configuration area. 

RULE C.2.3: 

All VXIbus slaves SHALL implement A16 addressing modes and have configuration registers available in the 
A16 address space. 

PERMISSION C.2.1: 

VXIbus slaves MAY also implement A24, A32 or A64 addressing modes. 

RULE C.2.4: 

IF a VXIbus slave implements A24, A32 or A64 addressing modes in addition to A16 addressing, 

THEN it SHALL implement only one of the additional addressing modes (A24, A32, A64). 

OBSERVATION C.2.1: 

The additional addressing modes (A16/A24, A16/A32 and A16/A64) are mutually exclusive to one another. If 
Enhanced Capability is defined in the ID Register, then the addressing mode of the device is defined in the 
Enhanced Capabilities Register. Currently A16/A64 is the only enhanced mode defined. 

RULE C.2.5: 

VXIbus slaves SHALL implement D16. 

RECOMMENDATION C.2.1: 

VXIbus slaves should implement DOS (EO). 

PERMISSION C.2.2: 

VXIbus slaves MAY implement D32 and/or D64. 

The preceding rules, etc. are summarized in the following table. 


IF 

A16 

A24 

A32 

A64 

THEN 

D08(EO) 

D16 

D32 

D64 

SLAVE A16 

• 

MAY 

MAY 

MAY 

REC. 

SHALL 

MAY 

MAY 

SLAVE A24 

SHALL 

• 

N.A. 

N.A. 

REC. 

SHALL 

MAY 

MAY 

SLAVE A32 

SHALL 

N.A. 

• 

N.A. 

REC. 

SHALL 

MAY 

MAY 

SLAVE A64 

SHALL 

N.A. 

N.A. 

• 

REC. 

SHALL 

MAY 

MAY 


N.A. - Not Allowed 
REC. - Recommended 

RULE C.2.6: 

VXIbus slaves SHALL NOT rely on A40 or MD32 modes for proper operation. 
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C.2.1.1.2 Configuration Registers 

The following diagram contains the register map for the Configuration registers of a VXIbus device. These 
registers are located in the A16 address space by the Logical Address selector as described previously. 
Revision 3.0 of this specification adds the Enhanced Capabilities Register at address 1C ig (formerly a device 
class dependent register). This location was chosen to facilitate backwards compatibility with existing 
modules because it is not defined for any Device Class by the VXI Consortium. 


3F 16 

DEVICE 


DEPENDENT 

20 16 

REGISTERS 

IE 16 

DEVICE CLASS DEPENDENT REGISTER 

1C 16 

Enhanced Capabilities Register 

IB 16 

DEVICE CLASS 


DEPENDENT 

08 16 

REGISTERS 

06 16 

Offset Register 

04 16 

Status/Control Register 

02 16 

Device Type 

00 16 

ID/Logical Address Register 


The fields of the above table are defined as follows: 

ID Register: A read of this 16-bit register provides information about the device's configuration. Its 
contents are defined in the following table. 


Bit# 

15 ^ 14 

13^ 12 

11^0 

Contents 

Device 

Class 

Address 

Space 

Manufacturer 

ID 


• Device Class: This field indicates the classification of the VXIbus device according to the 
following table. 


Value 

Class 

00 

Memory 

01 

Extended 

10 

Message Based 

11 

Register Based 
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• Address Space: This field indicates the addressing mode(s) of the device's operational registers 
according to the following table. 


Value 

Mode 

00 

A16/A24 

01 

A16/A32 

10 

Enhanced Capability 

11 

A16 Only 


• Manufacturer ID: This number uniquely identifies the manufacturer of the device. The list of ID numbers 
is maintained by the VXIbus Consortium. Each VXIbus device manufacturer has exactly one 
Manufacturer ID number. Numbers are assigned to manufacturers in decreasing order beginning with 
number 4095. See Section A.I, "Manufacturer ID Numbers", for information on obtaining a manufacturer 
ID number. 

OBSERVATION C.2.2: 

ID number 3840 (FOOis) is reserved for user customized devices and any other unique special function 
device. 

Logical Address: This 16-bit write register is defined by the optional Dynamic Configuration protocol. See 
Section F, "Dynamic Configuration". 

Device Type: This 16-bit register contains a device dependent type identifier. The read contents of this 
register are defined below 


Bit# 

15 ^ 12 

11^0 

Contents 

Required 

Memory 

Model 

Code 


• Required memory [Only required for A16/A24, A16/A32 and A16/A64 devices]: These 4 bits contain a 
number m, which is between 0 and 15. The required memory usage is defined as 


For Address Mode 

Memory usage = 

A16/A24 


A16/A32 

231-m 

A16/A64 

263-m 


The address mode for the device is found in the address space field of the ID register or if the address 
space field is set to enhanced capabilities (IO 2 ), then the address mode is found in the address mode field 
of the enhanced capabilities register. The appropriate equation from the above table gives the amount of 
A24, A32 or A64 memory space (in bytes) resident on the device. This also means that the device must 
decode addresses to this resolution. 

OBSERVATION C.2.3: 

The above algorithm for determining memory requirements allows devices with minimal memory 
requirements to let the Required Memory bits float to a high level and minimizes hardware requirements 
for low cost devices. 

In the case of an AI6 only device, these four bits are the upper bits of the Model Code 
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OBSERVATION C.2.4: 

The minimum size of an A24 device's memory is 256 bytes. The maximum size of the memory map is 1/2 
of the complete A24 VMEbus address space, i.e. 8,388,608 bytes (8 Mbytes). 

OBSERVATION C.2.5: 

The minimum size of an A32 device's memory is 65,536 bytes (64 kbytes). The maximum size of the 
memory map is 1/2 of the complete A32 VMEbus address space, i.e. 2,147,483,648 bytes (2 Gbytes). 

OBSERVATION C.2.6: 

The minimum size of an A64 device's memory is 281,474,976,710,656 (281 Tbytes). The maximum size 
of the memory map is 1/2 of the complete A64 VMEbus address space, i.e. 9,223,372,036,854,775,808 
bytes (9 Ebytes). 

SUGGESTION C.2.1: 

It would be a good idea to limit the memory space of any device to 1/4 of the available address range for 
the device. This would facilitate having more than one device in each possible address space. 

• Model Code: This field contains a unique card identifier which is defined by the manufacturer. In the case 
of an A16 only device, this field occupies all 16 bits of the Device Type register. 

OBSERVATION C.2.7: 

Model codes 0-255 (O-EEig are reserved for Slot 0 devices. See Rules C.4.18 and C.4.19 in Section C.4.3, 
"VXIbus Subsystem Slot 0". 

A write to the Device Type register location has no effect. Its use is reserved for VXIbus definition. 


Status Register: A read of this register provides information about the Device's status as defined in the 
following table. 


Bit# 

15 

14 

13 ^4 

3 

2 

1 ^0 

Contents 

A24/A32/A64 

Active 

MODID* 

Device 

Dependent 

Ready 

Passed 

Device 

Dependent 


• A24/A32/A64 Active: This bit is only required for A16/A24, A16/A32 or A16/A64 devices. A one (1) in 

this field indicates that its A24, A32 or A64 registers can be accessed. This bit reflects the state of the 
Control register's A24/A32/A64 Enable bit. 


RULE C.2.7: 

T\\& A24/A32/A64 Active bit in an A16/A24, A16/A32 and A16/A64 device SHALL be cleared (set to zero 
(0)) whenever SYSRESET* is asserted and changed only by a write of the A24/A32/A64 Enable bit in the 
device's Control register. 

OBSERVATION C.2.8: 

In an A16 only device the A24/A32/A64 Active bit is device dependent. 

• MODID*: A one (1) in this field indicates that the device is not selected via the P2 MODID line. A zero 
(0) indicates that the device is selected by a high state on the P2 MODID line. 

RULE C.2.8: 

IF A device does not implement MODID capability (PI only device) 

THEN the device's MODID* bit SHALL always be set to one (1). 

RULE C.2.9: 

IF A device implements MODID capability, 

THEN the device's MODID* bit SHALL always be set or reset within 1 ms of the module's MODID 
line being set or reset. 
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• Ready: This field serves two purposes: 

1. After the power-on initialization sequence (see Section C.2.1.2, "Device Initialization and 
Diagnostics") a one (1) in this field in combination wilh a zero (0) in Ihe Passed field indicates lhal Ihe 
device has failed register initialization. 

2. After Ihe power-on initialization sequence, a one (1) in Ihis field in combination wilh a one (1) in Ihe 
Passed field indicates lhal Ihe device is ready lo execute ils full sel of operational commands. 

OBSERVATION C.2.9: 

The Ready bil indicates lhal a device is ready lo accepl ils full sel of operational commands. This 
"readiness" is determined in a device dependenl manner. A standard definition of readiness for Message 
Based Devices is given in Section C.2.4.5, "Message Based Device Configuration". 

• Passed: A zero (0) in Ibis field indicates lhal Ihe device is eilher executing or has failed ils self lesl. A one 
(1) indicates lhal Ihe self lesl has successfully completed. 

RULE C.2.10: 

IF a device does nol implemenl a power-on self lesl, 

THEN ils Passed bil SHALL always be sel lo one (1). 

PERMISSION C.2.3: 

The device dependenl bils of Ihe Stains register MAY be defined lo indicate Ihe slate of Ihe corresponding bils 
of Ihe Conlrol register. 

Control Register: A write to this register causes specific actions to be executed by the device. 

These actions are described in the following table. 


Bit# 

15 

14^2 

1 

0 

Contents 

A24/A32/A64 

Enable 

Device 

Dependent 

Sysfail Inhibit 

Reset 


• A24/A32/A64 Enable: A one (1) in this field enables access to the device's A24, A32 or A64 VMEbus 
registers. A zero (0) disables such access. 

• Device Dependent: The bits in this field are available to the device designer for device and/or application 
specific control. 

OBSERVATION C.2.10: 

A Resource Manager which lacks device specific knowledge of a device will always write a one to each of 
the device dependent bits of a device's Control register whenever it writes to that Control register to 
change any of the VXIbus defined bits. 

RECOMMENDATION C.2.2: 

The device dependent bits of the Control register should be implemented so that writing ones to these bits 
will not disturb the initial state of the device. This will permit a Resource Manager or Commander (which 
lacks device specific knowledge) to write the VXIbus defined bits without causing some undesired activity 
on the device. 

• Sysfail Inhibit: A one (I) in this field disables the device from driving the SYSEAIL* line. 

• Reset: A one (1) in this field forces the device into a reset state. 

RULE C.2.11: 

IF a device's Commander writes a one (1) to the device's Reset bit, 

THEN the Commander must not write a zero (0) to that device's Reset bit within the following 

100 ms. 

See Section C.2.1.2, "Device Initialization and Diagnostics", for more information on the operation of the 
above bits. 
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Offset Register: This register is needed only for A16/A24, A16/A32 and A16/A64 devices. This 16-bit 
read/write register defines the base address of this device's A24, A32 or A64 operational registers. The m -i- 1 
most significant bits of the Offset register are the values of the m -i- 1 most significant bits of the device's A24, 
A32 or A64 register addresses, where m is the value of the Required Memory field of the device's Device Type 
register. The 15—m least significant bits of the Offset register are meaningless. Thus, the Offset register bits 
15 —> 15-m map to the address lines A 23 —> for A24 registers, to lines A 31 —> A 31 .,,, for A32 registers or to 

lines A 63 —> A 63 -m for A64 registers. 

OBSERVATION C.2.11: 

In the case of an A16 only device, the Offset register's location is a device dependent operational 

register. 

OBSERVATION C.2.12: 

A read of the Offset register always returns the address offset most recently written to the Offset 

register. 

OBSERVATION C.2.13: 

The Dynamic Configuration protocol defines additional use of the Offset register. See Section F, 

"Dynamic Configuration". 

Enhanced Capabilities Register: This register is only needed if the Address Space field of the ID register is 
set to IO 2 . This 16-bit register contains the address mode of the device if the address space field of the ID 
register is set to enhanced capabilities (value IO 2 ). The remaining bits of this register are reserved by the VXI 
consortium for future definition. 


Bit# 

15 ^3 

2^0 

Contents 

VXI Reserved 

Address 

Mode 


• VXI Reserved: Reserved for future implementation by the VXIbus Consortium. 

• Address Mode: This field indicates the enhanced capabilities addressing mode(s) of the device's 
operational registers according to the following table. 


Value 

Mode 

001^000 

RESERVED 

010 

A16/A64 

111^011 

RESERVED 


OBSERVATION C.2.14: 

In the case where the address space field of the ID register is set to AI 6 only, A16/A24 or A16/A32, 
the Enhanced Capabilities register's location is a device dependent operational register. 

OBSERVATION C.2.15: 

The Address Mode field of the Enhanced Capabilities Register has been defined such that, in future 
revisions of the specification, the values OOO 2 , OOI 2 and 01 12 can be used to respectively indicate the 
same addressing modes as the values OO 2 , OI 2 and II 2 indicate in the Address Space field of the ID 
register. This was done so that if a future version of the VXIbus Specification defines new capabilities 
to be reported in the Enhanced Capabilities register, all valid address modes can still be specified. 
This expanded sef of values was nol implemented in fhe Address Mode field in fhis version of fhe 
VXIbus Specificalion in order fo promote backward compafibilify wifh fhe insfalled base of Resource 
Managers. Thus, an AI 6 only, A16/A24 or A16/A32 device is currenfly required fo reporf ifs 
addressing modes in fhe Address Space field of fhe ID register. 

OBSERVATION C.2.16: 
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The enhanced capabilities setting should not be interpreted to solely mean A16/A64 mode. Although 
currently this is the only defined function, designers should be cognizant of the fact that additional 
features may be added in future revisions of the VXIbus specification. 

C.2.1.1.3 Device Class Dependent Registers 

The definition of the VXIbus Device Class Dependent Registers varies with the class of the device, i.e. 
Message Based, Register Based, etc. 

C.2.1.1.4 Device Dependent Registers 

VXIbus Device Dependent Registers are user definable. 

C.2.1.1.5 Address Modifiers 

Revision 3.0 of the VXIbus specification adds Extended Address Modifier (XAM) codes as defined by 
VME64x for use with the 2eVME protocol. 

RULE C.2.12: 

VXIbus device AI6 registers SHALL respond to address modifiers 29i6 (AI6 Non-Privileged Access) and 
2 Di 6(AI6 Supervisory Access) only. 

RULE C.2.13: 

VXIbus device A24 registers SHALL respond to address modifiers SDig (A24 Supervisory Data Access) and 
3 Ei 6 (A24 Supervisory Program Access). 

RECOMMENDATION C.2.3: 

VXIbus device A24 registers should also respond to address modifiers 39 le (A24 Non-Privileged Data Access) 
and 3 Ai 6 (A24 Non-Privileged Program Access). 

PERMISSION C.2.4: 

VXIbus device A24 registers MAY respond to any of the address modifiers 32i6 (A24 Lock Command), 38le 
(A24 Non-Privileged Multiplexed Block Transfer), 3Bi6 (A24 Non-Privileged Block Transfer), 3Ci6 (A24 
Supervisory Multiplexed Block Transfer) and 3Pi6 (A24 Supervisory Block Transfer). 

RULE C.2.14: 

VXIbus device A24 registers SHALL NOT respond to any address modifier other than 32i6, 38i6, 39i6, 3Ai6, 
3 Bi6, 3Ci6, 3Di6, 3Ei 6 or 3Pi6. 

RULE C.2.15: 

VXIbus device A32 registers SHALL respond to address modifiers ODie (A32 Supervisory Data Access) and 
0 Ei 6 (A32 Supervisory Program Access). 

RECOMMENDATION C.2.4: 

VXIbus device A32 registers should also respond to address modifiers 09 le (A32 Non-Privileged Data Access) 
and 0 Ai 6 (A32 Non-Privileged Program Access). 

RECOMMENDATION C.2.5: 

VXIbus device A32 registers in devices that require high performance should also respond to address modifier 
20 i 6 with XAM 01 le (6U, A32/D64 2eVME Transfer). 

PERMISSION C.2.5: 

VXIbus device A32 registers MAY respond to any of the address modifiers 05le (A32 Lock Command), 08le 
(A32 Non-Privileged Multiplexed Block Transfer), OBie (A32 Non-Privileged Block Transfer), OCie (A32 
Supervisory Multiplexed Block Transfer) and OEie (A32 Supervisory Block Transfer). 
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RULE C.2.16: 

VXIbus device A32 registers SHALL NOT respond to any address modifier other than OSig, OSie, 09i6, OAig, 
0 Bi6, 0Ci6, 0Di6, 0Ei6, 0Fi 6 or 20i6 w/XAM Olie. 

RULE C.2.17: 

VXIbus device A64 registers SHALL respond to address modifiers 01 ig (A64 Single Transfer Access). 

RECOMMENDATION C.2.6: 

VXIbus device A64 registers in devices that require high performance should also respond to address modifiers 
OOig (A64 64-bit Block Transfer [MBLT]), 03ig (A64 Block Transfer [BLT]) and 20ig with XAM 02ig (6U, 
A64/D64 2eVME Transfer). 

PERMISSION C.2.6: 

VXIbus device A64 registers MAY respond to address modifier 04ig (A64 Lock Command). 

RULE C.2.18: 

VXIbus device A64 registers SHALL NOT respond to any address modifier other than OOig, Olig, 03ig, 04ig or 
20ig w/XAM 02ig. 

OBSERVATION C.2.17: 

The preceding rules prevent any overlapping of the defined VMEbus address spaces. They do implicitly allow 
the use of address modifiers not specifically mentioned. 


C.2.1.2 DEVICE INITIALIZATION and DIAGNOSTICS 

The VMEbus provides a minimal self-test reporting facility (SYSFAIL*). VXIbus devices implement an 
extended reporting strategy that addresses the ambiguities of the VME64 specification. In addition, the 
VXIbus initialization process provides for a VXIbus device to initialize its own configuration registers. 


C.2.1.2.1 Overview 

The VXIbus initialization sequence provides the following services: 

Assertion of SYSFAIL* at power-on to indicate a self-test condition. 

Status register indication of self-test status. 

Optional faceplate LED indication of self-test status, labeled Failed. 

Time limit for completion of a normal self-test. 

Control register bits for disabling SYSFAIL* driver and resetting the device. 

A waiting period for initialization of the device's configuration registers. 

The initialization sequence is implemented with an internal state machine, the Passed and Ready bits of the 

Status register, the Reset and Sysfail Inhibit bits of the Control register, a VMEbus SYSFAIL* driver and the 

Failed LED. 

A typical power-on initialization sequence proceeds as follows. 

1. 1. At power-on SYSRESET* is asserted, forcing the device into a reset condition. At this time 
the Passed, Reset, Ready and Sysfail Inhibit bits are all cleared (to 0). The device asserts 
SYSFAIL* and lights its Failed LED (if present). 

2. When SYSRESET* is unasserted, the device begins its self test. This self test initializes the 
device's capability to execute VXIbus communication. 

3. If the device fails its self test, it leaves its Passed and Ready bits cleared, SYSFAIL* asserted and 
its Failed LED lighted. After 4.9 seconds, these conditions indicate a self test failure. 
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4. When the device successfully completes its self test, it sets (to 1) its Passed bit, de-asserts 
SYSFAIL* and turns off its Failed LED (if present). It is then ready to commence VXIbus 
communications. 

5. If the device requires further initialization, as in the case of a Message Based Device, its Ready bit 
remains cleared (to 0). When it is ready to accept its normal operational commands, it sets (to 1) 
its Ready bit. 

6. A VMEbus Master may turn off a failed device's SYSEAIL* driver by setting (to 1) its Sysfail 
Inhibit bit. It may also force the device into a reset condition by setting its Reset bit. 

7. When the Reset bit is cleared, the device begins another self test sequence. 

A device may initialize its configuration registers any time within the 4.9 seconds after the unassertion of 

SYSRESET*, typically in the following sequence. 

1. At power-on SYSRESET* is asserted, forcing the device into a reset condition, disabling all 
VMEbus access to its configuration registers. The device asserts SYSEAIL* and lights its Eailed 
LED (if present). 

2. When SYSRESET* is unasserted, the device begins initialization of its configuration registers. At 
this point VMEbus access remains disabled, SYSEAIL* remains asserted and the Eailed LED is 
lighted (if present). 

3. After initializing to zero (0) the Passed, Reset and Sysfail Inhibit bits and initializing to one (1) the 
Ready bit, the device may enable VMEbus access to its configuration registers. 

4. If the device is unable to initialize the Passed, Reset, Sysfail Inhibit and Ready bits, its 
configuration registers will remain inaccessible to the VMEbus. 

5. After initializing all of its configuration registers, the device enables VMEbus access to its 
registers (if it hasn't already), clears the Ready bit and begins its self test. 

6. If the device fails to completely initialize its configuration registers, it enables VMEbus access to 
its registers (if it hasn't already), leaves its Passed bit cleared, its Ready bit set, SYSEAIL* 
asserted and its Eailed LED lighted (if present). After 4.9 seconds, these conditions indicate an 
initialization error. 

7. When the device successfully completes both its configuration register initialization and its self 
test, it sets (to 1) its Passed bit, de-asserts SYSEAIL* and turns off its Eailed LED (if present). It 
is then ready to commence VXIbus communications. 

C.2.1.2.2 Self Test Operation 

The initialization sequence is characterized by eight states as illustrated in Eigure C.4. 

• Hard Reset: This is the state of the device when the SYSRESET* line is true. While in this state the 
device is inactive and its Status and Control registers may be initialized. The SYSEAIL* line is driven low 
and the failed LED is lighted. 

• Config Reg Init: During this optional state, the device configures its own configuration registers. This 
may include setting its Logical Address and its ID and Device Type register values, as well as initializing 
its Status, Control and Offset registers. Initially, a device's configuration registers may be inaccessible via 
the VMEbus. In this state, the device continues to assert SYSEAIL* and its optional Eailed LED is 
lighted. The config reg init state and any additional self test must complete within 4.9 seconds of 
SYSRESET*'s unassertion or clearing of the Reset bit. If the configuration register initialization fails 
before the device enables VMEbus access to its configuration registers, the device remains in the CONEIG 
REG INIT state until the next Hard Reset. Before register access is enabled, the Passed bit is set to zero 
(0) and the Ready bit is set to one (1). The ID and Device Type registers may be initialized either before 
or after register access is enabled. 
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• Self Test: In the Self Test state, the device tests and initializes the functionality necessary for VXIbus 
communications. This test must complete within 4.9 seconds of SYSRESET*'s unassertion or clearing of 
the Reset bit. If the self test fails, the device enters the failed state. If it passes, it enters the passed state. 
While in the self test state the device's VMEbus interface is active. However the device is incapable of 
responding to any commands other than Reset and Sysfail Inhibit. While in the SELE TEST state, the 
Passed bit remains cleared (to 0), the Ready bit is also cleared and SYSEAIL* remains asserted. 
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Figure C.4. Self Test State Diagram 


• Init Failed: This state is entered if the configuration register initialization fails after the device has enabled 
access of its configuration registers. While in the INIT FAILED state, SYSFAIL* is asserted, the Passed 
bit is set to zero (0) and the Ready bit is set to one (I). This state may be exited by either a Hard Reset or a 
Soft Reset. 

OBSERVATION C.2.18: 

The output indications are identical for the CONFIG REG INIT and INIT TAILED states. Therefore a 
completely failed device that is incapable of even beginning to initialize its configuration registers will 
correctly indicate an INIT TAILED status. 

• Tailed: This state is entered if the self test fails. While in the TAILED state, the Passed bit and the Ready 
bit remain cleared (to 0) and SYSEAIL* remains asserted. This state may be exited by either a Hard Reset 
or a Soft Reset. 
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OBSERVATION C.2.19: 

The output indications are identical for the SOFT RESET, SELE TEST and TAILED states. Therefore, a 
completely failed device that is incapable of even beginning a self test will correctly indicate a failed status. 

• Passed: This state is entered when the self test has successfully terminated. The SYSEAIL* line is 
unasserted and the Passed bit of the Status register is set (to 1). While in the PASSED state, the device is 
capable of fully supporting VXIbus communications. 

OBSERVATION C.2.20: 

The passed state can be further sub-divided in a device dependent manner. Eor Message Based Devices 
three sub-states are defined in Section C.2.4.4, "Message Based Device Operation". 

• Soft Reset: This state is entered when the Reset bit of the Control register is set to one. While in this state 
a device is inactive, interrupts which are pending are unasserted and all pending bus requests are removed. 
While in this state the device's VMEbus slave interface is active, however the device is incapable of 
responding to any commands other than Reset and Sysfail Inhibit. While in this state the Status register 
must accurately reflect the state of the device. 

OBSERVATION C.2.21: 

The VME64 Specification (Section 3.3.2, "Requester") defines the protocols for proper removal of bus 
requests. 

• Init Reset: This state is similar to the SOET RESET state, except that the device's configuration registers 
have not been initialized (and therefore are meaningless). 

The mnemonics used in the self test state diagram are listed in the following table: 


SELF TEST Mnemonics 

Mnemonic 

Name 

Type 

SRST 

SYSRESET* asserted (low) 

VMEbus line 

RST 

Reset (l=true) 

Confrol register bif 

Fail 

Self Test Failed 

Infernal signal 

Pass = 

Self Test Failed 

Infernal signal 

Dead = 

Device Failure 

Infernal signal 

Initialized = 

Config Regs Initialized 

Infernal signal 

Initfail = 

Init Config Regs Failed 

Infernal signal 


OBSERVATION C.2.22: 

The Fail, Pass and Dead signals are generated by the Initialization process as sequencing signals to itself. 

OBSERVATION C.2.23: 

The Dead signal is generated by the device whenever it detects a catastrophic failure during normal operation. 
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The states of the initialization sequence produce the Status register indications given in the following table. 


SELF TEST Status Bits 

State 

Status Register Bits 

Passed 

Ready 

HARD RESET 

(0) 

(0/1) 

CONEIG REG INIT 

(0) 

(1) 

INIT TAILED 

0 

1 

SELE TEST 

0 

0 

TAILED 

0 

0 

PASSED 

I 

1/1 

SOET RESET 

0 

0 

INIT RESET 

0 

1 


OBSERVATION C.2.24: 

The Status register is inaccessible during the HARD RESET state. However, in many cases its bits will be 
initialized by SYSRESET* to indicate the device's state (CONEIG REG INIT or SELE TEST) immediately 
following HARD RESET. 

OBSERVATION C.2.25: 

The device's configuration registers may be inaccessible throughout the CONEIG REG INIT state. The Status 
register indications shown are meaningful only after VMEbus access has been enabled. 

The status of the SYSEAIL* driver and the optional failed LED may be derived from the states of the Passed 
Status register bit and the Sysfail Inhibit Control register bit as described in the following table. 


SELF TEST Indicators 

Register Bits 

Indicators 

Passed 

Sysfail Inhibit 

SYSFAIL* 

FAILED 

Status Bit 

Control Bit 

Driver 

LED 

0 

0 

LOW 

ON 

0 

1 

HIGH 

ON 

1 

X 

HIGH 

OFF 
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The VMEbus SYSRESET* line and the Control register interact to force the device into particular states as 
described in the following table. 


SYSRESET* and Control Register Interactions 

Signal 

SYSRESET* 

Reset 

Current 

Effect 

Line 

Bit 

State 


LOW 

X 

X 

HARD RESET state 

t 

X 

HARD RESET 

Begin CONEIG REG INIT (if implemented) 
or SELE TEST 

HIGH 

1 

SELE TEST, PASSED, 
or EAILED 

SOET RESET State 

HIGH 

1 

INIT EAILED 

INIT RESET State 

HIGH 


SOET RESET 

Begin SELE TEST 

HIGH 


INIT RESET 

Begin CONEIG REG INIT 


RULE C.2.19: 

All devices implementing power-on self tests SHALL implement the HARD RESET, SELE TEST, PASSED, 
EAILED and SOFT RESET states of the self test function. 

RULE C.2.20: 

Any device not implementing the initialization sequence SHALL NOT assert SYSEAIL* or clear (to 0) its 
Passed bit at any time. 

RULE C.2.21: 

A device SHALL NOT implement a CONFIG REG INIT and SELE TEST combination of more than 
4.9 seconds total duration. 

RULE C.2.22: 

A device's ID and Device Type registers SHALL be valid before it enters the SELE TEST state. 

PERMISSION C.2.7: 

A device MAY execute self test operations while in the CONEIG REG INIT state, provided that its Ready bit is 
set (to 1), until its configuration registers have been initialized. 

RULE C.2.23: 

A device's VXIbus interface SHALL be fully operational before entering the PASSED state. 

PERMISSION C.2.8: 

A device MAY enter the EAILED state any time it detects a catastrophic failure during normal operation. 

OBSERVATION C.2.26: 

The Sysfail Inhibit bit of the Control register is used to disable the device's SYSEAIL* driver. 

OBSERVATION C.2.27: 

The Tailed LED is optional. Other LED's such as a SYSEAIL* inhibit indicator may also be optionally 
implemented. 
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OBSERVATION C.2.28: 

Once a device has enabled access of its configuration registers, they will remain accessible until the next Hard 
Reset. 

RULE C.2.24: 

Once a device enters either the INIT FAILED or SELF TEST state, it SHALL NOT change its Logical 
Address except as provided for by Dynamic Configuration (see Section F, "Dynamic Configuration"), until the 
next Hard Reset. 

OBSERVATION C.2.29: 

A Soft Reset will not affect a device's Logical Address, configuration register accessibility. Offset register or 
A24/A32/A64 Active bit. 

RULE C.2.25: 

After either a Hard Reset or a Soft Reset, a device SHALL remain deactivated until activated by its 
Commander. 

RULE C.2.26: 

A deactivated device SHALL NOT assert any VMEbus IRQ lines or initiate any data transfer cycles. 

OBSERVATION C.2.30: 

A Commander activates a device in a device dependent manner. A standard method of activating Message 
Based Devices is given in Section C.2.4.5, "Message Based Device Configuration". 

RULE C.2.27: 

A VXIbus device, other than a Resource Manager (see Section C.4.1, "Resource Manager"), SHALL NOT 
autonomously activate itself. 


C.2.1.3 PRIORITY INTERRUPTS 

Use of priority interrupts is optional for VXIbus devices. However all VXIbus devices recognize a standard 
format for the STATUS/ID word provided in response to interrupt acknowledge cycles. 

OBSERVATION C.2.31: 

Priority interrupts provide a mechanism for routing information between a device with an Interrupter and a 
device with an Interrupt Handler (on the same IRQ line). The Interrupt Handler might not be the intended 
recipient of the information. If an Interrupt Handler receives an interrupt which it recognizes to be intended for 
another device, it may forward the information carried by the interrupt, to the intended recipient via either a 
Signal or another interrupt. 


C.2.1.3.1 Interrupters 
RULE C.2.28: 

VXIbus devices with Interrupter capability SHALL allow the user to configure which Interrupt Request line 
(IRQ1*-IRQ7*) is used. 

RECOMMENDATION C.2.7: 

VXIbus Interrupters should implement Release On Acknowledge (ROAK). 

OBSERVATION C.2.32: 

Message Based Devices that are Interrupters are required to implement ROAK. See Section C.2.4, "Message 
Based Devices". 
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RULE C.2.29: 

Interrupters which implement D16 STATUS/ID Transfer capabilities SHALL also implement D08(O) 
STATUS/ID Transfer capabilities. 

RULE C.2.30: 

Interrupters which implement D32 STATUS/ID Transfer capabilities SHALL also implement D16 
STATUS/ID Transfer capabilities and D08(O) STATUS/ID Transfer capabilities. 

RULE C.2.31: 

VXIbus devices SHALL implement combined D08(O), D16 and D32 interrupt response modes such that the 
size of the STATUS/ID word is selected according to the type of interrupt acknowledge cycle detected, 
according to the following table. 


STATUS/ID Word size 

Cycle 

Combined Mode 

Type 

DOS 

D08/16 

D08/16/32 

8-Bit 

8 

8 

8 

16-Bit 

8 

16 

16 

32-Bit 

8 

16 

32 


OBSERVATION C.2.33: 

The VME64 specification requires that D08(O) Interrupters respond to 8-, 16- and 32-bit interrupt 
acknowledge cycles with an 8-bit STATUS/ID word. D16 Interrupters respond to 16- and 32-bit cycles with a 
16-bit word. 

OBSERVATION C.2.34: 

The preceding three rules guarantee that no matter what width STATUS/ID read the Interrupt Handler 
generates, the Interrupter will respond with the appropriate width of STATUS/ID. 

OBSERVATION C.2.35: 

Many VME64 Interrupt Handlers generate only D08 (O) STATUS/ID read cycles. The preceding three rules 
guarantee that Interrupters which respond to DI6 and D32 STATUS/ID cycles will also be able to respond to 
Interrupt Handlers which request D08 (O) responses. 

RULE C.2.32: 

All VXIbus Interrupters SHALL provide STATUS/ID responses to interrupt acknowledge cycles according to 
the format defined in the following table. 


Bit# 

31 ^ 16 

15 ^8 

7^0 

Contents 

D32 

Cause/ 

Logical 


Extension 

Status 

Address 


The fields of the STATUS/ID word are defined below. 

• D32 Extension: These optional bits may be provided by a D32 Interrupter in order to give additional 

information about its status or the cause of the interrupt. The value EEEEig is reserved to mean No 
Extension Given. Otherwise the format of this field is unspecified. 
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OBSERVATION C.2.36: 

If a DOS (or D16) Interrupt Handler reads a 32-bit STATUS/ID word, the upper 24 (or 16) bits of data will 
be lost. 

• Cause/Status: These bits give the cause of the interrupt and/or reflect the Interrupter's Status register. The 
value FFi 6 is reserved to mean No Cause/Status Given. 

OBSERVATION C.2.37: 

If a DOS Interrupt Handler reads a 16-bit STATUS/ID word, the upper S bits of data will be lost. 

• Logical Address: This field contains the Logical Address of the Interrupter device. 

RECOMMENDATION C.2.8: 

A VXIbus Interrupter should provide a means of masking VMEbus interrupts. 


C.2.1.3.2 Interrupt Handlers 
RULE C.2.33: 

VXIbus devices with Interrupt Handler capability SHALL allow the user to configure which Interrupt Request 
line (IRQ1*-IRQ7*) is monitored. 

RECOMMENDATION C.2.9: 

VXIbus Interrupt Handlers should implement D16 or D32 interrupt acknowledge cycles. 

SUGGESTION C.2.2: 

For compatibility with Non-VXIbus Interrupters, design VXIbus Interrupt Handlers to include D08(O) 
interrupt acknowledge cycle generation capability. 


C.2.1.4 VMEbus MASTER CAPABILITIES 

As discussed in the specific device class sections. Master capability is optional for Register Based and 
Extended VXIbus Devices, prohibited for Memory Devices and required for some Message Based Devices. 
The capabilities are intended to ensure compatibility with all VXIbus slaves, as well as with many non-VXIbus 
slaves. 


C.2.1.4.1 Bus Requesters 

VXIbus devices implement a fair requester protocol which requires that a level n requester, after receiving a 
bus grant via BGnIN*, may not request the bus again until at least 30 ns after the next low to high transition of 
Bus Requestline BRn*. This forces a Round Robin type of bus management on a single Bus Request/Grant 
level. This protocol is also known as Request on No Request (RONR). 

RULE C.2.34: 

All VXIbus devices with Master capability SHALL implement the Eair Requester protocol. 

OBSERVATION C.2.38: 

The above rule provides a more egalitarian environment than the standard VMEbus bus request protocols. 
This matches instrumentation requirements better than the default prioritization of devices provided by the 
daisy chains. 
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RULE C.2.35: 

VXIbus devices with Master capability SHALL use Bus Request/Grant level 3 as a default. 

RECOMMENDATION C.2.10: 

VXIbus devices with Master capability should allow the user to configure which Bus Request/Grant level is 
used. 

PERMISSION C.2.9: 

VXIbus devices with Master capability MAY provide the capability of selecting another type of Requester. 

OBSERVATION C.2.39: 

The above permission allows designers of high performance boards with real time constraints to implement bus 
locking. Not implementing a Fair Requester can cause system performance difficulties. 

RECOMMENDATION C.2.11 

IF a device has the Fair Requester disabled 

THEN it should be moved to another Bus Request/Grant level. 

RECOMMENDATION C.2.12: 

A VMEbus Master should implement cycle-by-cycle arbitration. A Master should not hold the bus while 
doing computation. In the case of a read from a device, a subsequent operation and then write to another 
device, the Master should allow arbitration of the VMEbus after the initial read. 

PERMISSION C.2.10: 

A VMEbus Master MAY maintain control of the data transfer bus for the time required to complete a Block 
Transfer Cycle. 

OBSERVATION C.2.40: 

The VME64 Specification allows for the possibility of a Master holding the data transfer bus (DTB) 
indefinitely. 


C.2.1.5 TERMINATING OPERATION 

A functioning VXIbus device terminates its operation in an orderly and consistent manner. This allows for 
putting devices off-line without adversely affecting other operating devices. It also allows for efficient 
reconfiguration of the VXIbus hierarchy. Eour different methods are available to a Commander or a Resource 
Manager for terminating the operations of a device. 

• Hard Reset: When the SYSRESET* line goes true all devices immediately terminate their operation. Hard 
Reset is used only when it is necessary to promptly terminate the operation of all devices in a VXIbus 
system. A Hard Reset will result in the system being configured by fhe Resource Manager. 

RECOMMENDATION C.2.13: 

Asserting SYSRESET* during operafion is a drasfic measure and should only be inifiafed to emulate a 
power-up cycle. 

• Soft Resef: A Commander may ferminafe fhe operafion of one of ifs Servanfs by setting to one (1) fhe 
Resef bif in fhe Servanf's Confrol register. 

RULE C.2.36: 

A Commander SHALL NOT Soft Resef any device nof in ifs Servanf lisf. 


PERMISSION C.2.11: 
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The Resource Manager MAY Soft Reset a Top Level device. 

• VXIbus commands: A Commander may terminate the operation of a Message Based Servant by sending it 
one of a number of low-level VXIbus commands. Refer to Section C.2.4.7, "Terminating Operation", for a 
detailed description of these commands. 

RULE C.2.37: 

Only a device's Commander may terminate the operation of that device by sending it a VXIbus device 
termination command. 

• Device dependent termination: A Commander may terminate the operation of a non Message Based 
Device in a device dependent manner, known to that Commander. The Servant ends up in a well-defined 
state (refer to Section C.2.2.4, "Terminating Operation"). 

RULE C.2.38: 

A Commander SHALL NOT use a device dependent method to terminate the operation of a Message 
Based Device. 

RULE C.2.39: 

When a device is terminated by a Soft Reset, a VXIbus command or in a device dependent manner, it 
SHALL retain the contents of its ID register. Device Type register. Offset register. Logical Address and 
the state of its A24/A32/A64 enable bit. 
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C.2.2 Register Based Devices 

A Register Based Device is generally a slave only device. Communication with one of these devices is usually 
accomplished via reads and writes of its registers. However, Register Based Devices may also utilize 
interrupts. One example of this class of device is a relay multiplexer device which is switched by writes to 
specific device registers. Register Based Devices are the simplest VXIbus devices and are suitable for low cost 
implementations. 

C.2.2.1 DATA TRANSFER CAPABILITIES 

OBSERVATION C.2.41: 

The VXIbus protocols provide no standard mechanism for identifying Register Based Devices with Master 
capability or for the regulation of the address space accessed by such devices. It is recognized that limited 
Master capability may in some cases be important for Register Based Servants. However, a Register Based 
Device with Master capability could make errant writes into unprotected address spaces unless such accesses 
are very closely guarded (such as in the case of a DMA capable disc interface). Care should be exercised to 
prevent the autonomous operation of a Register Based Device outside of the limits defined by its Commander. 


C.2.2.2 PRIORITY INTERRUPTS 

Register Based Devices are not required to use VMEbus interrupts. Some Register Based Devices may use 
interrupts for status reporting. 

RECOMMENDATION C.2.14: 

IF a Register Based Device has a status register bit to indicate a busy or not ready state, 

AND that bit can normally be asserted for periods longer than fifty microseconds (50 ms), 

THEN the device should have interrupt capability that may be enabled to be asserted at the end of the 
busy/not ready period. 

OBSERVATION C.2.42: 

The preceding recommendation is intended to minimize backplane traffic due to excessive polling of Status 
registers. 

OBSERVATION C.2.43: 

A Register Based Interrupter responds to interrupt acknowledge cycles with a STATUS/ID word conforming 
to the standard VXIbus format defined in Section C.2.I.3.I "Interrupters". 

The standard VXIbus STATUS/ID word format is illustrated in the following table. 


Bit# 

31 ^ 16 

15 ^8 

7^0 

Contents 

D32 

Extension 

Cause/ 

Status 

Logical 

Address 


OBSERVATION C.2.44: 

The Cause/Status and D32 Extension fields of the STATUS/ID word are optional. Their bit definitions are 
entirely device dependent for Register Based Devices. 
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C.2.2.3 REGISTER BASED DEVICE REGISTERS 

Register Based Devices have both VXIbus standard configuration registers and device dependent operational 
registers. The location and quantities of these registers are determined from the device's Logical Address and 
olher information stored by ils configuration registers (See Section C.2.1.1.2, "Configuration Registers"). The 
Address Space field of Ihe ID register or Ihe Address Mode field of Ihe Enhanced Capabilities register defines 
Ihe location of Ihe operational registers as follows. 

A16 Only: The operational registers occupy addresses Otiie — > SFig relative to Ihe device's A16 base 
address. 

A16/A24: The operational registers occupy addresses OSie —> SFig relative to Ihe device's A16 base 
address and a block of A24 addresses located by Ihe device's Offsel register 

A16/A32: The operational registers occupy addresses 08i6 —> SFig relative to Ihe device's A16 base 
address and a block of A32 addresses located by Ihe device's Offsel register 

A16/A64: The operational registers occupy addresses OSie —> IBie and lEie —> 3Fi6 relative to Ihe 
device's A16 base address and a block of A64 addresses located by Ihe device's Offsel register 

OBSERVATION C.2.45: 

All Register Based Device operational registers have device dependenl funclionalily. 


C.2.2.4 TERMINATING OPERATION 

Three differenl melhods are available for terminating Ihe operation of a Register Based Device. These are 
Hard Resel, Soft Resel and Device Dependenl Termination. The orderly termination of device operation 
allows for deactivating a device wilhoul adversely affecting olher operating devices. Il also allows for efficienl 
reconfiguration of Ihe VXIbus hierarchy. 

OBSERVATION C.2.46: 

When a VXIbus Register Based Device is deactivated il may nol asserl any VMEbus IRQ lines or inliale any 
dala Iransfers. 


C.2.2.4.1 Hard Reset 

Upon receipl of a Hard Resel (assertion of SYSRESET*), a Register Based Device enters, as does any olher 
device class, Ihe HARD RESET slate. From lhal slate a device continues ils initialization until il ends in one 
of Ihe possible slates as defined in Section C.2.1.2, "Device Initialization and Diagnostics". Hard Resel is used 
only when il is necessary to promplly terminate operation of all devices in a VXIbus system. A Hard Resel 
always affecls Ihe enlire VXIbus system and will resull in Ihe system being configured by Ihe Resource 
Manager. 


C.2.2.4.2 Soft Reset 

A Commander may terminate the operation of a Register Based Servant by setting to one the Reset bit in the 
Servant's Control register. When the Commander clears the Reset bit, a Register Based Device enters, as does 
any other device class, the SELF TEST state (refer to Section C.2.L2, "Device Initialization and Diagnostics"). 
If successful, the device will then enter the PASSED state. At this point, the device will be in a benign state 
with no links to any other devices. 

OBSERVATION C.2.47: 

A Soft Reset is the only non device dependent method available to a Commander for terminating the operation 
of a Register Based Servant. 
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OBSERVATION C.2.48: 

Register Based Device that has been Soft Reset may be inconsistent with the remainder of the system. It is 
important that such a device not be activated until all inconsistencies have been resolved. 

RULE C.2.40: 

Before a Commander reactivates a device after having Soft Reset that device, the Commander SHALL 
guarantee that the device is in a state consistent with the rest of the system. 

OBSERVATION C.2.49: 

A Register Based Device which has been Soft Reset is activated by its Commander in a device dependent 
manner. 

RULE C.2.41: 

A Register Based Device which has been Soft Reset SHALL retain its assigned Logical Address if it has been 
dynamically configured (refer to Section F, "Dynamic Configuration"). It SHALL also retain any 
A24/A32/A64 memory assignment. 


C.2.2.4.3 Device Dependent Termination 

Soft Resetting a device will cause it to go through its self test. It may be desirable for a Commander to simply 
deactivate a Register Based Device without having to go through self test. 

PERMISSION C.2.12: 

A Register Based Device MAY have a device dependent method other than Soft Reset that allows the device's 
Commander to terminate the device's operation. 

OBSERVATION C.2.50: 

A Register Based Device which has been deactivated in a device dependent manner is also reactivated by its 
Commander in a device dependent manner. 

RULE C.2.42: 

Before a Commander reactivates a device after having terminated its operation in a device dependent manner, 
the Commander SHALL guarantee that the device is in a state consistent with the rest of the system. 
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C.2.3 Memory Devices 

VXIbus Memory Devices provide either permanent or temporary data storage in the form of blocks of ROM, 
RAM, etc. in the VMEbus A24, A32 or A64 address space. The addresses of these memory blocks are 
configured via the VXIbus configuration registers. 


C.2.3.1 MEMORY DEVICE REGISTERS 

A Memory Device has both A16 configuration registers and A24, A32 or A64 operational registers. In 
addition it has an ATTRIBUTE REGISTER, which indicates the nature of its operational memory registers. 


C.2.3.1.1 Memory Device Attribute Register 

The attribute register is a read only register which lists important characteristics of the Memory Device. The 
following diagram contains the configuration register map for a Memory Device. 


3Fi6 

DEVICE 

1Ei6 

DEPENDENTREGISTERS 

lCi6 

Enhanced Capabilities Register 

1Bi6 

DEVICE 

0Ai6 

DEPENDENT REGISTERS 

08i6 

Attribute Register 

07i6 

CONEIGURATION 

00i6 

REGISTERS 


The Attribute Register has the following format. 

Attribute Register: 


Bit# 

15 ^ 14 

13 

12 

II 

10^8 

7 

6 

5^4 

3^0 

Contents 

Memory 

Type 

N/S 

BT* 

N_P* 

Access 

Speed 

D32* 

D64* 

RESERVED 

Device 

Dependent 


• Memory Type: These two bits contain information about the type of memory contained in this device. 


Bit# 

Meaning 

15 

14 

I 

I 

RAM 

0 

I 

ROM 

I 

0 

OTHER 

0 

0 

RESERVED 


• N/S: A one in this position indicates that the device is accessible in both Non-Privileged and Supervisory 
modes. A zero in this position indicates that the device is accessible only in Supervisory mode. 

• BT*: A zero in this position indicates that the device has Block Transfer Capability. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 






Page 152 


Section C: System Architecture 


• N_P*: The meaning of this field is dependent on the memory type field. If the memory type is RAM (11), 
a zero (0) in this field indicates that the RAM is non-volatile. If the memory type is ROM (01), a zero (0) 
in this field indicates that the device is electrically programmable. 

• Access Speed: The value in this field indicates fhe memory access limes, as listed in Ihe following fable. 


Bit# 

10 9 8 

Access Time (/) 

0 0 0 

0 ns <t < 50 ns 

0 0 1 

50 ns < f < 100 ns 

0 1 0 

100 ns < f < 200 ns 

0 1 1 

200 ns <t< 400 ns 

1 0 0 

400 ns <t< 800 ns 

1 0 1 

800 ns <t< 1600 ns 

1 1 0 

1600 ns <t 

1 1 1 

Device Dependent 


OBSERVATION C.2.51: 

The access lime is fhe maximum delay from fhe assertion DSO* or DSl* unlil fhe MEMORY device asserts 
DTACK*. 

• D32*: A zero in Ihis position indicates lhal fhe device's A24/32/64 registers supporl D32 Iransfers in 
addilion lo D16 and/or DOS. 

• D64*: A zero in Ihis position indicates lhal Ihe device's A24/32/64 registers supporl D64 Iransfers in 
addilion lo D32, D16 and/or DOS. 

• RESERVED: Reserved for fulure definition and musl defaull lo all ones (7ig). 

• Device Dependenl: These bils may be defined by Ihe device's manufaclurer. 

A write lo Ihe Allribules Register location has no effect Ils use is reserved for VXIbus definition. 


C.2.3.1.2 Memory Device Operation al Registers 

A Memory Device's operational registers are its functional memory locations. The location and quantities of 
these registers are determined from information stored in the device's configuration registers (See Section 
C.2.1.1.2, "Configuration Registers"). The, Address Space field of the ID register or the Address Mode field of 
the Enhanced Capabilities defines the location of the operational registers as follows. 

A16 Only: This configuration is undefined for Memory devices. 

A16/A24: The operational registers occupy a block of A24 addresses located by 
register. 

A16/A32: The operational registers occupy a block of A32 addresses located by 
register. 

A16/A64: The operational registers occupy a block of A64 addresses located by 
register. 

PERMISSION C.2.13: 

A Memory Device's A16 device dependent registers MAY be used for device specific purposes. 


the device's Offset 
the device's Offset 

the device's Offset 
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C.2.4 Message Based Devices 

Message Based Devices support the VXIbus configuration and communication protocols. All Message Based 
Devices are capable of al leasl a minimum sel of standard communicalion protocols. Examples of Message 
Based Devices are any sophislicaled devices wilh local intelligence lhal require a level of communicalion 
capability such as DMM's, Speclrum Analyzers, Display Conlrollers, 488-VXIbus interface devices, Swilch 
conlrollers, elc. 

C.2.4.1 DATA TRANSFER CAPABILITIES 

Message Based Devices ulilize a standard sel of registers to implemenl Ihe VXIbus messaging protocols. 
These registers operate in Ihe A16 address space and require D16 capability. 

RULE C.2.43: 

All Message Based Commanders SHALL have A16 and D16 Master capability. 

RECOMMENDATION C.2.15: 

All Message Based Devices should have A16 and D16 Master capability. 

OBSERVATION C.2.52: 

Servanl-only devices wilh A16 Master capability are able to send stains messages to Iheir associated 
Commanders efficienlly, wilhoul Ihe use of priority inlerrupls. 

RECOMMENDATION C.2.16: 

All Message Based Devices should have A24 Master capability. 

RULE C.2.44: 

All Message Based Al 6 Masters SHALL be capable of accessing Ihe enlire A16 address range. 

RULE C.2.45: 

All Message Based A24 Masters SHALL be capable of accessing Ihe enlire address range from 200000ig 
Ihrough DFFFFFig. 

PERMISSION C.2.14: 

A Message Based A24 Master MAY be capable of accessing Ihe enlire A24 address range from 000000 ig 
Ihrough FFFFFFig. 

SUGGESTION C.2.3: 

Message Based Devices should have D08 (EO) Master capability. 

OBSERVATION C.2.53: 

D08 (EO) Master capability facilitates compalibilily wilh a broader range of Non-VXIbus devices lhan would 
olherwise be possible. 

PERMISSION C.2.15: 

Message Based Devices MAY implemenl A32, A64, D32 and/or D64 Master capabililies. 

OBSERVATION C.2.54: 

A32 Master capability is required for conlrol of any A32 Register Based or Memory devices or any A32 Non- 
VXIbus devices. 

OBSERVATION C.2.55: 

A64 Master capability is required for conlrol of any A64 Register Based or Memory devices or any A64 Non- 
VXIbus devices. 

RULE C.2.46: 

All Message Based A32 Masters SHALL be capable of accessing Ihe enlire A32 address range from 
20000000 ig Ihrough DFFFFFFFig. 
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RULE C.2.47: 

All Message Based A64 Masters SHALL be capable of accessing the entire A64 address range from 
0000000000000000 16 through FFFFFFFFFFFFFFFFie- 

PERMISSION C.2.16: 

A Message Based A32 Master MAY be capable of accessing the entire A32 address range from 00000000le 
through FFFFFFFFie- 

OBSERVATION C.2.56: 

VXIbus protocols support the inclusion of A24, A32 or A64 RAM in Message Based Devices. 

The preceding rules, etc. are summarized in the following table. 



AI6 

A24 

A32 

A64 

DOS (EO) 

DI6 

D32 

D64 

MASTER 

S/R 

REC 

MAY 

MAY 

SUG. 

S/R 

MAY 

MAY 

SLAVE 

SHALL 

MAY 

MAY 

MAY 

MAY 

SHALL 

MAY 

MAY 


SUG. - Suggested. 

RFC - Recommended. 

S/R - SFIALL for Commanders. Recommended for others. 


C.2.4.2 PRIORITY INTERRUPTS 

RECOMMENDATION C.2.17: 

A Message Based Device should implement either VMEbus Master or Interrupter capability. 

Interrupt Handler capability is entirely optional. 

OBSERVATION C.2.57: 

The Asynchronous Mode Control command may be used to select and enable the transmission mode (interrupt 
or signal) of the different classes (response and event) of interrupts. 

RULE C.2.48: 

Message Based devices with Interrupter capability SHALL implement Release On Acknowledge (ROAK). 

Three word serial commands are defined to allow a device's Commander to query and modify the interrupt 
lines selected by a Message Based Device with Interrupter capability. These commands are: 

Read Interrupters - This command is used to read the number of interrupt lines the device may drive 
simultaneously, i.e. the number of Interrupters in the device. 

Read Interrupter Line - This command is used to read which VMEbus interrupt line is driven by a 
particular Interrupter in the device. 

Assign Interrupt Line - This command is used to assign one of the device's Interrupters to a 
particular VMEbus interrupt line. 

Within a device, multiple Interrupters are identified in some device dependenf consecufive order, sfarfing wifh 
#1. They are designafed Interrupter#!, Interrupter#2, efc. 

RECOMMENDATION C.2.18: 

A Message Based Device wifh Infermpfer capabilify should implemenf Programmable Infermpfer (PI) 
capabilify, which provides a mechanism fo program and read back each infermpf line connecfion fo fhaf 
device's Inlerrupler(s). This is achieved by supporting fhe Read Interrupters, Read Interrupter Line and Assign 
Interrupter Line commands. 
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PERMISSION C.2.17 

Message Based Commanders MAY implement Interrupt Handler capability. 

Three word serial commands are defined to allow a device's Commander to query and modify the interrupt 
lines selected by a Message Based Device with Interrupt Handler capability. These commands are: 

Read Handlers - This command is used to read the number of interrupt lines the device may handle 
simultaneously, i.e. the number of Interrupt Handlers in the device. 

Read Handler Line - This command is used to read which VMEbus interrupt line is handled by a 
particular Interrupt Handler in the device. 

Assign Handler Line - This command is used to assign one of the device's Interrupt Handlers to a 
particular VMEbus interrupt line. 

Within a device, multiple Interrupt Handlers are identified in some device dependent consecutive order, 
starting with #1. They are designated Handler #1, Handler #2, etc. 

RECOMMENDATION C.2.19: 

A Message Based Device with Interrupt Handler capability should implement Programmable Handler (PH) 
capability, which provides a mechanism to program and read back each interrupt line connection to that 
device's Interrupt Handler(s). This is achieved by supporting the Read Handlers, Read Handler Line and 
Assign Handler Line commands. 

RULE C.2.49: 

IF a Message Based Device implements Interrupter capability 

THEN it SHALL respond to an interrupt acknowledge with the 16-bit Status/ID word defined in the 
following tables. 

There are two different formats for the STATUS/ID word, distinguished by the value of its bit #15. 


Bit# 

31 ^ 16 

15 

14^8 

7^0 

Contents 

D32 

Extension 

0 

Response 

Logical 

Address 


Bit# 

31 ^ 16 

15 

14^8 

7^0 

Contents 

D32 

Extension 

0 

Event 

Logical 

Address 


The fields of the STATUS/ID word are defined below. 

• D32 Extension: The contents of this optional field are device dependent. 

OBSERVATION C.2.58: 

D08(O) and D16 STATUS/ID generators will always return EEEEig in this field. 

• Response: This field is identical to bits 14 <— 8 of the device's Response register as defined in Section 
C.2.4.3.1, "Message Based Device Communication Registers". 

OBSERVATION C.2.59: 

A Message Based Device will not generate any response signals or response interrupts unless such 
response signals or response interrupts have been enabled by the Control Response command. 
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OBSERVATION C.2.60: 

Devices which are not capable of generating response signals or response interrupts are not required to 
support the Control Response command. 

• Event: This field indicates the event associated with the interrupt. See Section E.4, "Protocol Events", 
for a listing of the defined events. 

OBSERVATION C.2.61: 

D08(O) STATUS/ID generators will always return EE16 in bits 15 <— 8. 

• Logical Address: This field contains the Logical Address of this device 

OBSERVATION C.2.62: 

The VXIbus provides alternate mechanisms for transmitting responses and events: interrupts and signals (See 
the Signal register definition in Section C.2.4.3.1, "Message Based Device Communication Registers"). Non¬ 
master devices always transmit via interrupts, while master devices may send signals. Some devices are 
capable of receiving only signals, whereas others may be only Interrupt Handlers. The VMEbus provides only 
seven (7) interrupt lines. In a large system these lines may be overloaded. Such a system may provide a 
mechanism for converting signals to interrupts, converting interrupts to signals or even translating from one 
interrupt line to another. 


C.2.4.3 MESSAGE BASED DEVICE REGISTERS 

Message Based Devices have both VXIbus standard configuration registers and operational registers. The 
location and quantities of these registers are determined from the device's Logical Address and other 
information stored by its configuration registers (See Section C.2.1.1.2, "Configuration Registers"). The 
Address Space field of the ID register or the Address Mode field of the Enhanced Capabilities defines the 
location of the operational registers as follows. 

A16 Only: The operational registers occupy addresses Ofiig —>3Ei6 relative to the device's A16 base 
address. 

A16/A24: The operational registers occupy addresses 08i6 —>3Eig relative to the device's A16 base 
address and a block of A24 addresses located by the device's Offset register 

A16/A32: The operational registers occupy addresses 08i6 —> 3Ei6 relative to the device's A16 base 
address and a block of A32 addresses located by the device's Offset register 

A16/A64: The operational registers occupy addresses 08i6 —> IBig and lEig —> 3Ei6 relative to the 
device's A16 base address and a block of A64 addresses located by the device's Offset register 

OBSERVATION C.2.63: 

All Message Based Device A24, A32 and A64 operational registers have device dependent functionality. 


C.2.4.3.1 Message Based Device Communication Registers 

Message Based Devices implement a standard set of A16 operational registers, known as communication 
registers. These registers are shown in the following table. The addresses are relative to a device's A16 base 
address. A block of registers is reserved for use by future optional protocols. It is anticipated that the 
definition of these registers will be tied to the definition of the reserved bits in the Protocol register. 

The communication registers are organized as follows: 
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3Fi6 

DEVICE 

DEPENDENT 

REGISTERS 

1Fi6 

VXVIbus 

1Ei6 

RESERVED REGISTERS 

lCi6 

Enhanced Capabilifies Register 

1Bi6 

VXVIbus 

18i6 

RESERVED REGISTERS 

14i6 

A3 2 Pointer 

10l6 

A24 Pointer 

0Ei6 

Dafa Low 

0Ci6 

Dafa High 

0Ai6 

Response/Dafa Extended 

08i6 

Protocol/Signal Register 


CONEIGURATION 

00i6 

REGISTERS 


RULE C.2.50: 

All Message Based Devices SHALL implement the Protocol, Response and Data Low registers. 

OBSERVATION C.2.64: 

The Signal, Data Extended, Data High, A24 Pointer and A32 Pointer registers are optional. 

The communication registers are defined as follows: 

Protocol Register: The read contents of this 16-bit register indicate which protocols the device supports 
and indicate additional communication capabilities of the device. 


Bit# 

15 

14 

13 

12 

11 

10 

9 

8 

7<-4 

3^0 

Contents 

CMDR* 

Signal 

Register* 

Master* 

Interrupter 

FHS* 

Shared 

Memory* 

D32* 

D64* 

RSVD 

Dev Dep 


• CMDR*: A one (1) in this field indicates that the device has Servant only capability. A zero (0) in this 
field indicates that the device has both Servant and Commander capability. 

• Signal Register*: A zero (0) in this field indicates fhaf fhe device has a Signal register. See below for a 
definilion of a Signal register. 

• Master*: A zero (0) in fhis field indicates fhaf fhe device has VMEbus Masfer capability. 

• Inferrapfer: A one (1) in fhis field indicates fhaf fhe device has Interrupter capabilify. 

• EHS*: A zero (0) in fhis field indicafes fhaf fhis device's dafa registers support fhe Easf Handshake mode 
(See Secfion C.3.3.2, "Easf Handshake Transfers"). A one (1) indicates fhaf only fhe normal Iransfer mode 
is implemented. 

• Shared Memory*: A zero (0) in fhis field indicates fhaf fhis device supporfs fhe opfional shared memory 
protocol (See VXI-9^^\ "Shared Memory Communicafion Protocol Specificalion") and implemenfs one or 
bofh of fhe A24 Poinfer and A32 Pointer registers. A one (1) indicafes fhaf fhe shared memory protocol is 
nol supported. 
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• D32*: A zero in this position indicates that all of the device's A24/32 registers support D32 transfers in 
addition to D16 and/or DOS. 

• D64*: A zero in this position indicates that all of the device's A24/32 registers support D64 transfers in 
addition to D32, D16 and/or DOS. 

• RSVD: Reserved for future definition and must default to all ones (3Fi6). 

• Dev Dep: These device dependent bits may be defined by the device's manufacturer. 


Signal Register: A write to this 16-bit register is used for general device to device signaling. For efficient 
system operation the Commander must be capable of detecting and responding quickly to any Signal register 
write. A signal consists of the Logical Address of the sender and other signal specific information. 

There are two different formats for the signals, distinguished by the value of its bit #15. 


Bit# 

15 

14^8 

7^0 

Contents 

0 

Response 

Logical 

Address 


Bit# 

15 

14^8 

7^0 

Contents 

1 

Event 

Logical 

Address 


The fields of the signal are defined below. 

Response: This field is identical to bits 14 <— 8 of the device's Response register as defined below. 

Event: This field indicates the event associated with the signal. 

OBSERVATION C.2.65: 

Response signals are generally used to respond to a request made by a device. Event signals are generally 
asynchronous events analogous to interrupts. The Asynchronous Mode Control command may be used to 
select and enable the transmission mode (interrupt or signal) of the different classes (response and event) of 
signals and interrupts. 

RULE C.2.51: 

IF a Message Based Device implements a functional Signal register, 

THEN there SHALL be a Write mode Location Monitor at the Signal register address. 

RULE C.2.52: 

IF a Message Based Device supports D08(EO) writes to its Signal register, 

THEN its Signal register DOS Location Monitor SHALL detect odd byte accesses only. 

RULE C.2.53: 

IF a write to a device's Signal register would result in loss of data, 

THEN that device SHALL respond to such a write by asserting RETRY* or BERR* instead of DTACK*. 
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RECOMMENDATION C.2.20: 

A device should exercise the VME64 Retry capability when a write to its signal register would result in loss of 
data. 

OBSERVATION C.2.66: 

A loss of data would occur if a signal write were to overwrite a previous signal that had not yet been read by 
the device's internal microprocessor. 

OBSERVATION C.2.67: 

A device may delay the DTACK*, RETRY* or BERR* handshake up to 20 //s (see RULE B.2.1) in an effort 
to prevent data loss. 

OBSERVATION C.2.68: 

If a write to a device's Signal register results in a bus error or retry indication, then that signal will not be 
received by the device. In such a case the sender may choose to retransmit the signal. 

RECOMMENDATION C.2.21: 

When a write to a device's signal register results in a RETRY* or BERR* indication, the bus master should 
retry the write a reasonable number of times before reporting the error in a device specific manner. 

PERMISSION C.2.18: 

A Message Based Device MAY implement a non-functional Signal register. This is indicated by a "1" in bit 14 
of the device's Protocol register. In this case the device may respond with DTACK* to Signal register writes, 
even though it stores no data from that write cycle. 

RECOMMENDATION C.2.22: 

If a Commander is intended to support a variety of Servants and configurations, it should implement a 
functional Signal register and the receipt of signals. 

Response Register: A read of this 16-bit register returns the status of the device's communication registers and 
their associated functions. 

The Message Based device's Response register indicates critical device status information. Each bit indicates a 
single status item as follows: 


Bit# 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6^0 

Contents 

0 

RESERVED 

DOR 

DIR 

Err* 

Read 

Ready 

Write 

Ready 

EHS 

Active 

Locked* 

Device 

Dependent 


The fields of the Response register are defined below. 

• Bit 15 is always zero. 

OBSERVATION C.2.69: 

Bit 15 is defined to be zero in order to provide consistency with the format of signals and Interrupter 
STATUS/ID words. 

• RESERVED: This bit is reserved for future VXIbus definition. Its value is always one (1). 

• DOR (Data Out Ready) [optional]: A one indicates that the device is ready to output data to its 
Commander. Its operation is described in Section C.3.3.3, "Byte Transfer Protocol". 
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OBSERVATION C.2.70: 

• Devices that support the Byte Request command are required to implement the DOR bit. 

• DIR (Data In Ready) [optional]: A one indicates that the device is ready to accept data from its 
Commander. Its operation is described in Section C.3.3.3, "Byte Transfer Protocol". 

OBSERVATION C.2.71: 

Devices that support the Byte Available command are required to implement the DIR bit. 

• Err* (Error) [required]: A zero (0) indicates that an error has occurred in one of the serial protocols 
(Word Serial, Longword Serial or Extended Longword Serial. See Section C.3.3.1, "Serial Protocols") 
and has not yet been reported. A one (1) indicates that all such codes have been reported via the Read 
Protocol Error command. See Section C.3.3.4, "Error Handling". 

OBSERVATION C.2.72: 

The Read Protocol Error command is used to report the reason for an assertion of the Err* bit. 

• Read Ready [Required]: A one indicates that its data registers contain data to be read. This bit is set 
when data from internal operations is available in the Data Low and Data High registers. It is cleared 
to zero by a read of the Data Low register. 

RULE C.2.54: 

The Read Ready bit SHALL be cleared before DTACK* is released during any data transfer cycle that 

reads the Data Low register. A device SHALL NOT clear its Read Ready bit at any other time, except as 

outlined in Table C.2. 

• Write Ready [Required]: A one indicates that this device is ready for data transfers to its data registers. 
This bit is set when the device is ready for a write to any of the data registers. It is cleared by a write 
to the Data Low register. 

RULE C.2.55: 

The Write Ready bit SHALL be cleared before DTACK* is released during any data transfer cycle that 

writes to the Data Low register. A device SHALL NOT clear its Write Ready bit at any other time. 

• LHS Active* [optional]: A zero indicates that Last Handshakes are currently enabled for this device's 
Servant registers (See Section C.3.3.2, "Last Handshake Transfers"). This bit is cleared (to 0) 
whenever the Last Handshake Mode is entered and set (to 1) any time the device exits the Last 
Handshake Mode. 

• Locked* [optional]: A zero indicates that the Commander of this device has locked access to it from 
other local sources, (e.g., local lockout of IEEE-488) 

• Device Dependent: The bits in this field are available to the device designer for device and/or 
application specific status information. 

RULE C.2.56: 

Each Message Based device SHALL be implemented in such a manner that each of the Response register bits 
13 <— 8 maintains its current state whenever the device modifies any other Response register bit(s). 

OBSERVATION C.2.73: 

The preceding rale cannot be satisfied by an implementation which requires a read-mask-write sequence to 
update the Response register, if that sequence allows an intervening access of the Data Low register (which 
will clear either the Read Ready or Write Ready bit) by another device. 
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OBSERVATION C.2.74: 

Transitions of any of bits 14 <— 8 of the Response register may be enabled to generate response interrupts or 
response signals as defined in Section C.2.4.2, "Priority Interrupts". 

Data Extended Register: A write to this optional register is the most significant word of input data or a 
command. 

PERMISSION C.2.19: 

A Message Based Device MAY implement a non-functional Data Extended register. 

RULE C.2.57: 

IF a Message Based Device implements a functional Data Extended register, 

THEN there SHALL be a Write mode Location Monitor at the Data Extended register address. 

RULE C.2.58: 

IF a Message Based Device supports D08(EO) writes to its Data Extended register, 

THEN its Data Extended register D08 Location Monitor SHALL detect odd byte accesses only. 

Data High Register: A write to this optional register is the second least significant word of write data. A read 
of this register is the most significant word of read data. 

PERMISSION C.2.20: 

A Message Based Device MAY implement a non-functional Data Extended register. 

RULE C.2.59: 

IF a Message Based Device implements a functional Data Extended register, 

THEN there SHALL be a Write mode Location Monitor at the Data Extended register address. 

RULE C.2.60: 

IF a Message Based Device supports D08(EO) writes to its Data Extended register, 

THEN its Data Extended register D08 Location Monitor SHALL detect odd byte accesses only. 

Data Low Register : A write to this register is the least significant word of write data. A write to this register 
causes the device to execute some action based on the data written to the Data High, Data Low and Data 
Extended registers. A read of this register is the least significant word of read data. 

RULE C.2.61: 

There SHALL be a Read mode and a Write mode Location Monitor at the Data Low register's address. 

RULE C.2.62: 

IF a Message Based Device supports D08(EO) accesses of its Data Low register, 

THEN its Data Low register D08 Location Monitors SHALL detect odd byte accesses only. 

OBSERVATION C.2.75: 

The Location Monitors at the data registers provide the device with the ability to detect the width of the data or 
command being sent. 16-bit, 32-bit and 48-bit data transfers can all be independently detected by this 
information. 

A24 Pointer Register: This 32- bit register is defined by the optional Shared Memory protocol. See VXI-9, 
"Shared Memory Communication Protocol Specification". 

A32 Pointer Register: This 32-bit register is defined by the optional Shared Memory protocol. See VXI-9, 
"Shared Memory Communication Protocol Specification". 

VXIbus Reserved Registers: These registers are reserved for future VXIbus definition. The effects of reads 
and writes of these registers are undefined. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 



Page 162 


Section C: System Architecture 


C.2.4.4 MESSAGE BASED DEVICE OPERATION 

The specification of standard communication protocols requires that all Message Based Devices have a 
uniform and clearly defined behavior when using common resources. For a Message Based Device, Ihree sub- 
slales are added in Ihe PASSED slate defined in Seclion C.2.1.2, "Device Inilializalion and Diagnostics". The 
firsl, CONFIGURE sub-slale, is Ihe slate in which a Message Based Device is configured. The second, 
NORMAL OPERATION sub-slale, is Ihe slate which is entered when Ihe configuration has been completed. 
Transitions belween Ihese slates are initialized by Ihe Begin Normal Operation, End Normal Operation and 
Abort Normal Operation commands. The Ihird sub-slale, INITIALIZE, is Ihe slate of Ihe device while il is 
executing Ihe Begin Normal Operation command. 

The sub-slales and Ihe Iransilions belween Ihem are described in Figure C.5 as an extension lo Figure C.4. All 
slate Iransilions already defined in Figure (Section C.2.1.2, "Device Initialization and Diagnostics") are Ihe 
same. 


From 



BNO_FAIL: 
BNO_REC: 
BNO_CMPLT: 
ENO_CMPLT: 
ANO CMPLT: 


Begin Normal Operation command failed 
Begin Normal Operation command received 
Begin Normal Operation command successfully completed 
End Normal Operation command successfully completed 
Abort Normal Operation command successfully completed 


Figure C.5. Configure Slate Diagram 
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OBSERVATION C.2.76: 

The CONFIGURE, INITIALIZE and NORMAL OPERATION sub-states are undefined in all states other than 
PASSED. 

RULE C.2.63: 

All Message Based Devices SHALL support word serial transfers when in the PASSED state (See Section 
C.2.1.2, "Device Initialization and Diagnostics"). 

OBSERVATION C.2.77: 

Some Message Based Devices may exhibit very long startup or boot, times. Such devices may be unable to 
receive or respond to word serial commands for a significant time interval following power-on. Such devices 
will hold off word serial transactions by the appropriate Response register indications, i.e. by holding the Write 
Ready and/or Read Ready bits to zero (0). There is no maximum response time requirement for such devices 
and they will delay the system configuration process executed by the Resource Manager. When a Resource 
Manager encounters such a device it may either wait indefinitely for a response or time out within some 
reasonable period. 

RULE C.2.64: 

While in the CONEIGURE sub-state, a Message Based Device SHALL remain deactivated. 

OBSERVATION C.2.78: 

A deactivated device may not assert any VMEbus IRQ lines or initiate any data transfer cycles. 


C.2.4.4.1 State Dependency of Commands 

A Message Based Device responds to different sets of commands depending on the sub-state it is in: 
CONEIGURE, INITIALIZE or NORMAL OPERATION. Some commands are used in all states. Whether the 
commands in the sets are mandatory or optional is defined in Section C.2.4.4.2, "Required Commands". 

The commands responded to in the CONEIGURE sub-state are called configuration commands: 

• Assign Handler Line 

• Assign Interrupter line 

• Grant Device 

• Identify Commander 

• Release Device 

• Read Servant Area 

The commands responded to in the NORMAL OPERATION sub-state are called normal operation commands: 

• Byte Available 

• Byte Request 

• Clear Lock 

• Read STB 

• Set Lock 

• Trigger 

• User Defined 

The commands responded to in both the CONEIGURE and the NORMAL OPERATION sub-states are called 
state independent commands: 

• Abort Normal Operation 
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• Asynchronous Mode Control 

• Begin Normal Operation 

• Clear 

• Control Event 

• Control Response 

• End Normal Operation 

• Read Handler Line 

• Read Handlers 

• Read Interrupter Line 

• Read Interrupters 

• Read MODID 

• Read Protocol 

• Read Protocol Error 

• Set Lower MODID 

• Set Upper MODID 

RULE C.2.65: 

A Commander SHALL NOT send any normal operation commands to a Servant which is in the CONFIGURE 
sub-state. 

RULE C.2.66: 

A Commander SHALL NOT send any configure commands to a Servant which is in the NORMAL 
OPERATION sub-state. 

OBSERVATION C.2.79: 

It is a protocol violation to send any commands to any device while it is in the INITIALIZE sub-state. 


C.2.4.4.2 Required Commands 

This section defines minimal conformance requirements for Message Based Devices in terms of their 

capabilities and sub-states. In this context a phrase of the form "A Message Based Device shall properly 

respond to..." means that: 

• The Message Based Device must support at least the minimum capability implied by the command. 

• The Message Based Device must recognize and interpret the command in a manner consistent with the 
intent of the command. 

• The Message Based Device must implement full functional support of the command, according to its 
capabilities. 

• If the command requires a response, the Message Based Device's response must conform to the response 
formats defined in Section E, "Command and Event Eormats". 
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RULE C.2.67: 

All Message Based Devices SHALL properly respond to the following commands in both the CONFIGURE 
and NORMAL OPERATION sub-states: 

• Abort Normal Operation 

• Begin Normal Operation 

• Clear 

• End Normal Operation 

• Read Protocol 

• Read Protocol Error 

RULE C.2.68: 

All Message Based Devices with VMEbus Master capability SHALL properly respond to the following 
command in the CONEIGURE sub-state: 

• Identify Commander 

OBSERVATION C.2.80: 

VMEbus Master capability is indicated by the Master* bit in the Protocol register. 

RULE C.2.69: 

All Message Based Commanders SHALL properly respond to the following commands in the CONEIGURE 
sub-state: 

• Read Servant Area 

• Grant Device 

• Release Device 

OBSERVATION C.2.81: 

Message Based Commander capability is indicated by the CMDR* bit in the Protocol register. 

RULE C.2.70: 

All Message Based Devices having Programmable Handler capability SHALL properly respond to the 
following commands in both the CONEIGURE and NORMAL OPERATION sub-states: 

• Read Handlers 

• Read Handler Line 

RULE C.2.71: 

All Message Based Devices having Programmable Handler capability SHALL properly respond to the 
following command in the CONEIGURE sub-state: 

• Assign Handler Line 

OBSERVATION C.2.82: 

Programmable Handler capability is indicated by the response to the Read Protocol command. 

RULE C.2.72: 

All Message Based Devices having Programmable Interrupter capability SHALL properly respond to the 
following commands in both the CONEIGURE and NORMAL OPERATION sub-states: 

• Read Interrupters 

• Read Interrupter Line 
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RULE C.2.73: 

All Message Based Devices having Programmable Interrupter capability SHALL properly respond to the 
following command in the CONFIGURE sub-state: 

• Assign Interrupter Line 

OBSERVATION C.2.83: 

Programmable Interrupter capability is indicated by the response to the Read Protocol command. 

RULE C.2.74: 

IF a Message Based Servant implements response interrupts or response signals, 

THEN it SHALL have the Response Generation (RG) capability. 

RULE C.2.75: 

All Message Based Devices having Response Generation capability SHALL properly respond to the following 
commands in the CONFIGURE or NORMAL OPERATION sub-state: 

• Asynchronous Mode Control 

• Control Response 

RULE C.2.76: 

A Message Based Device having Response Generation capability SHALL enable or disable response 
generation on each Response register bit transition for which it supports response generation, in response to the 
Control Response command. 

OBSERVATION C.2.84: 

Response Generation capability can be determined by the Read Protocol command. 

RULE C.2.77: 

IF a Message Based Servant implements event interrupts or event signals, 

THEN it SHALL have the Event Generation (EG) capability. 

RULE C.2.78: 

All Message Based Devices having Event Generation capability SHALL properly respond to the following 
command in the CONFIGURE or NORMAL OPERATION sub-state: 

• Asynchronous Mode Control 

• Control Event 

RULE C.2.79: 

A Message Based Device having Event Generation capability SHALL enable or disable event generation for 
each event it is capable of generating, in response to the Control Event command. 

OBSERVATION C.2.85: 

Event Generation capability can be determined by the Read Protocol command. 


C.2.4.5 MESSAGE BASED DEVICE CONFIGURATION 

The specification of standard communication protocols requires that all Message Based Devices be configured 
in a uniform fashion after a Hard Reset, Soft Reset or after receiving one of the word serial Abort Normal 
Operation, End Normal Operation or Clear commands. 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 



Section C: System Architecture 


Page 167 


C.2.4.5.1 The Default Configuration 

Message Based Devices have a uniform default configuration. The default configuration is assumed when the 
devices are reset or receive the Abort Normal Operation command. The configuration may be modified (from 
the default) with the configuration commands. The resulting configuration becomes active when the device 
enters the NORMAL OPERATION sub-state. 


RULE C.2.80: 

Upon entering the PASSED state, a Message Based Device SHALL assume the CONEIGURE sub-state with 
the default configuration wherein: 


1 . IF the Message Based Device is a Commander, 

THEN its Servant list is empty. 

2. Responses and events are globally enabled (See the definition of the Asynchronous Mode Control 
command in Section E.l, "Word Serial Commands"). 


3. IF 
THEN 

4. IF 
THEN 

5. IF 
THEN 

6 . IF 
THEN 


the Message Based Device has VMEbus Master capability, 
responses and events are sent via signals to Logical Address 0 (zero). 

the Message Based Device does not have VMEbus Master capability, 
responses and events are sent via interrupts. 

the Message Based Device has Programmable Interrupter capability, 
the Interrupter capabilities are not connected to any IRQ lines. 

the Message Based Device has Programmable Handler capability, 
the Interrupt Handler capabilities are not connected to any IRQ lines. 


7. Generation of all supported events is enabled. (See the definition of the Control Event command 
in Section E.l, "Word Serial Commands".) 

8. Generation of B14*, DOR*, DIR*, Err*, RR*, WR*, EHS* responses is disabled. (See the 
definition of the Control Response command in Section E.l, "Word Serial Commands".) 


9. The device is not processing any incoming signals or interrupts. 

OBSERVATION C.2.86: 

Since the device is de-activated in the CONEIGURE sub-state, even though responses and events may be 
enabled, signals and interrupts are not generated until the device enters the NORMAL OPERATION sub-state. 


The default configuration is summarized in Table C.l. 


C.2.4.5.2 Modifying The Configuration 

Changes can be made to the current configuration in the CONEIGURE sub-state using the configuration 
commands and state independent commands. 

RULE C.2.81: 

Upon receipt of the Grant Device command, a Commander SHALL add the granted device to its Servant list. 

OBSERVATION C.2.87: 

Each Commander maintains a list of the Logical Addresses of Servant devices, referred to as the Servant list. 
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DEFAULT CONFIGURATION 

Identify Commander: 

Resource Manager 

Asynchronous Mode: 

Events 

Responses 

Enabled (via signals if Bus Master) 
Enabled (via signals if Bus Master) 

Control Response: 

All Bits Disabled 

Control Event: 

All Events Enabled 

Programmable Handlers 

All Disconnected 

Programmable Interrupters 

All Disconnected 

Servant List 

Empty 


TABLE C.l. The Default Configuration 

RULE C.2.82: 

Upon receipt of the Release Device command, a Commander SHALL delete the released device from its 
Servant list. 

RULE C.2.83: 

IF a Message Based Device supports the Identify Commander command, 

THEN upon receipt of the Identify Commander command, the Message Based Device SHALL register the 
identified Commander as the device's Commander. 

RULE C.2.84: 

IF a Message Based Device supports the Assign Handler Line command, 

THEN upon receipt of the Assign Handler Line command the Message Based Device SHALL connect the 
IRQ line to the Interrupt Handler capability. 

RULE C.2.85: 

IF a Message Based Device supports the Assign Interrupter Line command, 

THEN upon receipt of the Assign Interrupter Line command the Message Based Device SHALL connect the 
IRQ line to the Interrupter capability. 


C.2.4.6 INITIATING OPERATION 

Once configured, a Message Based Device is activated via the Begin Normal Operation command. Receipt of 
the Begin Normal Operation command causes a device to initialize its Servants and enter the NORMAL 
OPERATION sub-state. While in the NORMAL OPERATION sub-state, the device will have its Ready bit set 
to one (1). 

OBSERVATION C.2.88: 

While in the NORMAL OPERATION sub-state the Commander/Servant hierarchy and the interrupt line 
configuration cannot be changed, according to Section C.2.4.4.1, "State Dependency of Commands". 
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OBSERVATION C.2.89: 

The Begin Normal Operation command indicates, via the Top Level bit, whether a device is a Top Level 
device or not. A top level device has no Commander and in the NORMAL OPERATION sub-state it may 
operate autonomously with respect to all other devices except a device involved in runtime resource 
management. A device involved in runtime resource management retains the capability of forcing a top level 
device into the CONFIGURE sub-state by sending the End Normal Operation or the Abort Normal Operation 
command to the top level device. 

RULE C.2.86: 

Upon the receipt of a Begin Normal Operation command, a Commander which is in the CONFIGURE sub¬ 
state SHALL execute the following process. 

1. Enter the INITIALIZE sub-state. 

2. Discard all pending and initiated signals and VMEbus interrupts. 

3. Determine which Message Based Servants are VMEbus Masters by reading the Protocol register. 

4. Send the Identify Commander command to all Message Based Servants which are VMEbus Masters. 

5. Send the Begin Normal Operation command to all Message Based Servants and wait for their responses. 

6. Configure all its non-Message Based Servants as needed. This includes allocating IRQ lines. 

7. If the above process is successful, enter the NORMAL OPERATION sub-state and set to one (I) the 
Ready bit of the Status register. Otherwise, return to the CONFIGURE sub-state. 

8. Return the appropriate response, indicating the state(s) of itself and its hierarchical Servants, in the Data 
Low register. This response will incorporate any device failure information returned (in response to 
Begin Normal Operation) by the Commander's Servants. 

OBSERVATION C.2.90: 

In general, a device will enter the NORMAL OPERATION sub-state if it is capable of normal operation. 

RULE C.2.87: 

Upon the receipt of a Begin Normal Operation command, a Commander which is in the NORMAL 
OPERATION sub-state SHALL return the appropriate response, indicating the state(s) of itself and its 
hierarchical Servants, in the Data Low register. 

OBSERVATION C.2.91: 

Since a device in the NORMAL OPERATION sub-state has already initialized its Servants, no action other 
than the response specified in fhe previous rule is required. 

RULE C.2.88: 

A Message Based Device which is in eifher fhe CONFIGURE or INITIALIZE sfafe SHALL have fhe Ready 
bif of ifs Sfafus register cleared fo zero (0). 

RULE C.2.89: 

A Message Based Device which is in fhe NORMAL OPERATION sub-slale SHALL have fhe Ready bif of ifs 
Sfafus register sef fo one (I). 

OBSERVATION C.2.92: 

Normally, fhe Resource Manager will configure a Message Based Device wifh PI capability fo drive an IRQ 
line fhaf ifs Commander handles. 
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OBSERVATION C.2.93: 

A Servant may be programmed to drive an IRQ line which is not handled by its Commander. 

OBSERVATION C.2.94: 

It is the responsibility of the system integrator to ensure that the IRQ lines are properly allocated. 

RULE C.2.90: 

A VXIbus device SHALL NOT attempt to control, through the VXIbus registers, any VXIbus device not in its 
own Servant list. 

RULE C.2.91: 

A Commander lacking device specific knowledge SHALL NOT access any of its Servants' device dependent 
registers other than the VXIbus defined regisfers. 

OBSERVATION C.2.95: 

If is nof safe fo assume fhaf a Commander may freely write fo any device dependenf register of a Servanf 
Device. Such accesses should nof (in general) be aflempled wifhouf good cause. 


C.2.4.7 TERMINATING OPERATION 

Four mefhods are available for ferminafing fhe operafion of Message Based Devices. These are Hard Resef, 
Sofl Resef, Abort Normal Operation and End Normal Operation. Each of fhese differ in fhe level of 
reconfiguration fhey impose on fhe device. Table C.2 ouflines fhe acfions imposed by fhese mefhods. Also 
included in fhe fable are fhe acfions imposed by fhe Clear command. Though fhe Clear command, as defined 
for Message Based Devices (Section C.2.4.8, "Clearing a Message Based Device"), does nof terminate fhe 
operation of fhe received device, if has been included in fhis fable for completeness. 


C.2.4.7.1 Hard Reset 

Upon receipf of a Hard Resef (assertion of SYSRESET*), a Message Based Device enfers, as does any ofher 
device fype, fhe HARD RESET sfafe. Erom fhaf sfafe a device continues ifs inifializafion unfil if ends in one of 
fhe possible slates as defined in Section C.2.1.2, "Device Initialization and Diagnostics". A Message Based 
Device will, if if enters fhe PASSED slate, enter fhe CONEIGURE sub-slate configured wilh fhe defaull 
configuration. 

Hard Resef is used only when if is necessary fo promplly lerminale operation of all devices in a VXIbus 
syslem. A Hard Resef always affecls fhe enlire VXIbus syslem and will resull in fhe system being configured 
by fhe Resource Manager. 


C.2.4.7.2 Soft Reset 

Upon receipt of a Soft Reset (setting and clearing the Reset bit), a Message Based Device enters, as does any 
other device type, the SOET RESET state. Erom that state a device passes through SELE TEST state until it 
ends in one of the possible states as defined in Section C.2.1.2 "Device Initialization and Diagnostics". A 
Message Based Device will, if it enters the PASSED state, enter the CONEIGURE sub-state configured with 
the default configuration. 

A Soft Reset affects only a single device and is used to deactivate a device. A deactivated device is prevented 
from using the VXIbus. 
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Hard Reset 

Soft Reset 

ANO 

ENO 

Clear 




Abort Normal 

End Normal 

Clear 

Generated By 

SYSRESET* 

Reset Bit 

Operation 

Operation 

Command 




Command 

Command 


Action Defined 

Upon Entry 

Upon Entry 

After 

After 

After 

to PASSED 

to PASSED 

Command 

Command 

Command 


State 

State 

Processed 

Processed 

Processed 

All Devices: 






Sub-Sfafe 

CONEIGURE 

CONEIGURE 

CONEIGURE 

CONEIGURE 

CONEIGURE 

Configuration 

Default 

Default 

Default 

Unchanged 

Unchanged 

Status Register: 






A24/A32/A64 

Active 

0 

Unchanged 

Unchanged 

Unchanged 

Unchanged 

Offset Register: 

Initial 

Unchanged 

Unchanged 

Unchanged 

Unchanged 

Logical Address: 

Initial 

Unchanged 

Unchanged 

Unchanged 

Unchanged 

Response Register: 






Err* bit 

1 

1 

1 

I 

I 

Read Ready 

0 

0 

Valid 

Valid 

0 

FHS Active * 

1 

1 

1 

1 

Unchanged 

Locked* 

1 

1 

1 

1 

Unchanged 

Bus Masters: 






Data Transfers 

No 

No 

No 

No 

Unchanged 

Interrupters: 






IRQ Assertions 

No 

No 

No 

No 

Unchanged 


TABLE C.2. Message Based Device Termination and Clear Actions 

RECOMMENDATION C.2.23: 

In general, a Commander should Soft Reset a Message Based Servant only if all VXIbus termination 
commands fail. 

OBSERVATION C.2.96: 

A Message Based Device that has been Soft Reset will have all of its configuration parameters reset (to the 
Default Configuration). Its state may also be inconsistent with the remainder of the system, due to lost signals 
or abandoned communication links with other VXIbus devices. It is important that such a device not be 
activated until its configuration is restored and all inconsistencies have been resolved. In general, the Resource 
Manager is the only entity capable of doing so. 
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RULE C.2.92: 

When a Commander soft resets a device it SHALL ensure that operation of all Servants of that device is also 
terminated. 

OBSERVATION C.2.97: 

In general, the Resource Manager is the only device with full knowledge of Servant hierarchies. 

RULE C.2.93: 

Before a Commander sends Begin Normal Operation to a Servant after having soft reset that Servant, the 
Commander SHALL guarantee that the device and the system are in a consistent configuration and state. 

OBSERVATION C.2.98: 

When a Commander receives Begin Normal Operation while it is in the CONFIGURE sub-state, the 
Commander can assume that all its Servants are in a state and configuration consistent with the system. 


C.2.4.7.3 Abort Normal Operation 

An Abort Normal Operation affects only a single device and is used by a Commander or by the Resource 
Manager to deactivate a device, i.e. prevent it from using the VXIbus. After an Abort Normal Operation, a 
Message Based Device will enter the CONFIGURE sub-state configured with the default configuration. In 
contrast to the Soft Reset, the device does not pass through the SELF TEST state. 

RECOMMENDATION C.2.24: 

In general, a Commander should send the Abort Normal Operation command to one of its Servants only after 
an attempt to send End Normal Operation had already failed. 

RULE C.2.94: 

Upon the receipt of the Abort Normal Operation command in the NORMAL OPERATION sub-state, a 
Message Based Device SHALL respond in the following manner: 

1. Abort operation as fast as possible. 

2. Exit the NORMAL OPERATION sub-state to the CONFIGURE sub-state, clearing the Ready bit of its 
Status register to zero (0). 

3. Stop processing incoming signals and interrupts. 

4. Restore the default configuration (the Logical Address and programmed offset is kept). 

5. Return the appropriate code in the Data Low register. 

RULE C.2.95: 

Upon the receipt of the Abort Normal Operation command in the CONFIGURE sub-state, a Message Based 
Device SHALL respond in the following manner: 

1. Restore the default configuration (the Logical Address and programmed offset is kept). 

2. Return the appropriate code in the Data Low register. 

OBSERVATION C.2.99: 

As a consequence of (re)entering the CONFIGURE sub-state, the response signal or interrupt generation is 
disabled and all pending bus requests and interrupts are unasserted. 

OBSERVATION C.2.100: 

Abort Normal Operation is not propagated through the hierarchy. 
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OBSERVATION C.2.101: 

A device that has been Aborted will have all of its configuration parameters reset (to the Default 
Configuration). Its state may also be inconsistent with the remainder of the system, due to lost signals or 
abandoned communication links with other VXIbus devices. It is important that such a device not be activated 
until its configuration is restored and all inconsistencies have been resolved. In general, the Resource Manager 
is the only entity capable of doing so. 

RULE C.2.96: 

When a Commander terminates the operation of a device with the Abort Normal Operation command it 
SHALL ensure that operation of all Servants of that device is also terminated. 

OBSERVATION C.2.102: 

In general, the Resource Manager is the only device with full knowledge of Servant hierarchies. 

RULE C.2.97: 

Before a Commander sends Begin Normal Operation to a Servant after having aborted that Servant's operation, 
the Commander SHALL guarantee that the device and the system are in a consistent configuration and state. 

OBSERVATION C.2.103: 

When a Commander receives Begin Normal Operation while it is in the CONFIGURE sub-state, the 
Commander can assume that all its Servants are in a state and configuration consistent with the system. 


C.2.4.7.4 End Normal Operation 

An End Normal Operation command affects a hierarchy of devices and is used by a Commander or by the 
Resource Manager to bring the devices into a state from which they can be restarted. After a successful End 
Normal Operation command, the devices in the hierarchy are deactivated. 

RULE C.2.98: 

Upon the receipt of the End Normal Operation command in the NORMAL OPERATION sub-state, a Message 
Based Device SHALL respond in the following manner: 

1. Allow operation to complete in a device specific consistent manner. All operation shall eventually end, 
but there is no time limit. 

2. Bring any Register Based or Extended Device Servants into a deactivated state. 

3. Send the End Normal Operation command to all its Message Based Servants and wait for their responses. 

4. Stop processing incoming signals and interrupts. 

5. Exit the NORMAL OPERATION sub-state to the CONEIGURE sub-state, clearing the Ready bit of the 
Status register to zero (0). The current configuration is kept. 

6. Return the appropriate response code in the Data Low register. This response will incorporate any device 
failure information returned (in response to End Normal Operation) by the Commander's Servants. 

RULE C.2.99: 

Upon the receipt of the End Normal Operation command in the CONEIGURE sub-state, a Message Based 
Device SHALL return the appropriate response code in the Data Low register. 
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OBSERVATION C.2.104: 

Since a device in the CONFIGURE sub-state has already been deactivated, no action other than the response 
specified in the previous rule is required. 

OBSERVATION C.2.105: 

As a consequence of entering the CONFIGURE sub-state, the device is deactivated i.e. prevented from using 
the VXIbus. 

OBSERVATION C.2.106: 

Those state parts (e.g. higher level configurations) which are not covered by the rules in this section can upon 
reception of End Normal Operation be changed in any manner that is device specific or may be sfandardized in 
fhe fufure. 

OBSERVATION C.2.107: 

The End Normal Operation command is propagafed from Commander fo Servanf unfil if has reached fhe 
boffom of fhe hierarchy. 

OBSERVATION C.2.108: 

If is device-dependenf if or how a device resumes operafion on receipf of Begin Normal Operation affer End 
Normal Operation. 


C.2.4.8 CLEARING A MESSAGE BASED DEVICE 

A Clear command is used only fo remove pending oufpul dafa from a Message Based Device's Dafa Low, 
High and Extended registers. Jusl as Abort Normal Operation and End Normal Operation, if may have an 
addifional meaning to higher level protocols. 

RULE C.2.100: 

Upon fhe receipf of fhe Clear command, a Message Based Device SHALL: 

Remove any dafa oufpuf in fhe Dafa Low, Dafa High and Dafa Extended regisfers. 

Remove any buffered dafa oufpuf fo fhe Dafa Low, Dafa High and Dafa Extended regisfers. 

Discard oufpuf dafa from any oufpuf dafa generafing operafions previously sfarled. 

Become ready to receive a new command. 

Clear (to 0) fhe Read Ready bif of ifs Response register. 

De-asserf fhe Err* bif of fhe Response register and cancel any pending Read Profocol Error command 
responses. 

RULE C.2.101: 

The Clear command SHALL NOT affecl: 

The CONFIGURE/NORMAL OPERATION sub-slale. 

The PI or PH sellings. 

The Servanf lisl. 

The Signal register. 

Assertion of IRQ lines. 

Communicalion links wilh olher VXIbus devices. 
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OBSERVATION C.2.109: 

The effects of Clear on a VXIbus instrument are documented in Section D.1.1.3, "Clearing a VXIbus 
Instrument". 


C.2.5 Extended Devices 

An Extended device is a VXIbus device with provisions for defining new subclasses of VXIbus devices for 
future applications. Each Extended Device has a subclass register in addition to its configuration registers. 
The subclass register allows for the definition of both standard and manufacturer specific Extended Device 
subclasses. 

OBSERVATION C.2.110: 

An Extended Device implements the standard set of VXIbus configuration registers. 

RULE C.2.102: 

An Extended Device SHALL implement a subclass register. 

The Extended Device register map is illustrated in the following table: 


3Fi6 

SUBCLASS 


DEPENDENT 

20i6 

REGISTERS 

1Ei6 

Subclass Register 

1Di6 

SUBCLASS 


DEPENDENT 

08i6 

REGISTERS 


CONEIGURATION 

00i6 

REGISTERS 


The registers are defined as follows: 

Subclass Register: The read contents of this 16-bit register indicate the subclass of the device. This 
register has two alternate formats depending on the value of bit 15: 


Bit# 

15 

14<-0 

Contents 

1 

Reserved Subclass 


Bit# 

15 

14-^12 

ll<-0 

Contents 

0 

Manufacturer Subclass 

Manufacturer ID 


Bit 15 is used to differentiate between VXIbus defined subclasses and manufacturer defined 

subclasses. The other fields are defined as follows: 

• Reserved Subclass: These bits identify the device's subclass. All values of this field are reserved 
for future VXIbus definition. 

• Manufacturer Subclass: These bits indicate the device's subclass as defined by a particular VXIbus 
manufacturer. The values of this field are defined by the manufacturer indicated by the adjacent 
Manufacturer ID field. 

• Manufacturer ID: These bits identify the manufacturer responsible for the definition of this 
particular subclass. The format is the same as in the Manufacturer ID field of the ID register (See 
Section C.2.1.1.2, "Configuration Registers"). 
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OBSERVATION C.2.111: 

Each VXIbus manufacturer may define up to 8 Extended Device Subclasses. Each of these subclasses 
has a unique Manufacturer Subclass/ID combination. 

The effects of writes to the Subclass Register location are subclass dependent. 

Subclass Dependent Registers: These registers will be defined according to a device's subclass requirements 
as a part of that subclass's definition. 
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C.3 DEVICE COMMUNICATION PROTOCOLS 

This section describes the protocols necessary for proper communication between VXIbus devices. 


C.3.1 Communication Elements 

C.3.1.1 REGISTER BASED SERVANTS 

Register Based Servant describes the communication element of a Register Based device. A Register Based 
Servant responds to no defined protocols, since the device's registers are entirely card dependent. 


C.3.1.2 MESSAGE BASED SERVANTS 

These devices are generally capable of independently executing complex commands and may also control 
other devices in a hierarchical instrumentation system. Message Based Servants communicate using the 
VXIbus Message Based device protocols. 


C.3.1.3 MESSAGE BASED COMMANDERS 

A Message Based Commander is the interface for a Message Based Device exercising control over other 
devices. Message Based Commanders communicate using the VXIbus Message Based Device protocols. 


C.3.2 Register Based Servant Control 

The protocols for control of Register Based Devices are completely device dependent. The designer of a 
Register Based Device is free to specify any register interactions and control protocols required for proper 
operation of that device. 


C.3.3 Message Based Servant Control 

The protocols for Commander —> Servant communication involve the Servant's Protocol, Response and Data 
registers. They may optionally utilize the Commander's Signal register or the VMEbus interrupts. The 
simplest communications use the data and Response registers to transfer data in a word serial fashion. This 
mode is defined as the Word Serial protocol. All Message Based Devices implement 16-bit word serial 
transfers. The 16-bit word serial transfer is the most basic method of communication defined for Message 
Based Devices. It is simple to implement (in both hardware and software), yet provides the required 
communication capability to achieve system objectives. 

Communication between Message Based Devices is established with 16-bit word serial transfers, then, upon 
notification of device capabilities, may progress to more sophisticated protocols. These may include higher 
performance word serial transfers as well as shared memory protocols. A Commander uses the read protocol 
command to determine which higher performance protocols are supported by a Servant. 

RULE C.3.1: 

All Message Based Devices SHALL implement the read protocol command. 
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C.3.3.1 WORD SERIAL PROTOCOLS 

The Word Serial Protocol is a communication protocol in which data words are transferred serially to or from 
a fixed location, in this case the read or write data register of the Servant. 

The word serial protocols are based upon a generalized model of a full duplex UART (Universal 
Asynchronous Receiver/Transmitter). Each implementation utilizes bidirectional data registers and a Response 
register. The data registers are categorized as full duplex, because reads and writes are totally independent. 
Each write to the data registers is interpreted as a command, unless a previous command has defined it as data. 
Commands may contain embedded data or may require supporting data to be transferred in succeeding writes. 
Such command/data sequences are generally not interruptible. 

Progress of a data transfer is paced by bits in the Response register which indicate whether the write data 
registers are empty and whether the read data registers are full. 

Data may be written into the write data registers only when the Write Ready bit in the Response register is set 
(1). When data is placed in the write data registers, the Write Ready bit is cleared (to 0) until the data is 
accepted by the Servant. 

Valid data may be read from the read data registers only when the Read Ready bit in the Response register is 
set (1). When the data is read from the read data registers, the Read Ready bit is cleared (to 0) until the Servant 
places another word in the read data registers. 

A Servant will source data to its read data registers only in response to a command. It is up to its Commander 
to read such data before issuing a command requiring the output of more data. Thus the Servant is not required 
to maintain an output queuing structure. 

PERMISSION C.3.1: 

A Commander MAY issue a command requiring a Servant to write more than one response to its read data 
registers. 

RULE C.3.2: 

A Servant SHALL NOT source any data to its read data registers except in response to an explicit request (for 
one or more data words) by that device's Commander. 

OBSERVATION C.3.1: 

If a Commander reads a Servant's data registers without first explicitly requesting the data, the Servant will 
either respond by causing a bus error or return unspecified data (with or without an error indication). Thus the 
Servant will either prevent the erroneous read, detect the error or ignore the protocol violation. 

RULE C.3.3: 

A Commander SHALL NOT send any command requiring a Servant to place data in its data registers until the 
Commander has read (from the data registers) all data generated by previous commands (and the Read Ready 
bit is zero (0)). 

OBSERVATION C.3.2: 

The preceding rale does NOT restrict the implementation of output queuing structures within higher level 
protocols. 

Three forms of word serial communications are defined in this section: Word Serial transfers (16-bit), 
Longword Serial transfers (32-bit) and Extended Longword Serial transfers (48-bit). Support for the 
Longword and Extended Longword serial transfers is optional. Data transfers utilizing any of these three 
protocols may be freely intermixed with data transfers of the other two protocols. 
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OBSERVATION C.3.3: 

Longword and Extended Longword transfers to a Servant that does not support these protocols is meaningless 
and will have unpredictable results. 

OBSERVATION C.3.4: 

Every Message Based Device has write mode Location Monitors at each of its supported data registers (Data 
Low, Data High and Data Extended). These Location Monitors indicate to the device which protocol is being 
invoked by its Commander for each transfer. 

OBSERVATION C.3.5: 

The command sets for all forms of word serial communication are orthogonal (mutually exclusive). The 
command sets are described in Section E, "Command and Event Eormats". 


C.3.3.1.1 Word Serial Transfers 

The word serial transfer is the minimum usable data transfer protocol. The data path width is 16 bits (one 
word). 

Data is transferred by reads or writes of the Data Low register. By default, all writes are interpreted as 
commands. Each transfer affects the state of the appropriate bit (Read Ready or Write Ready) of the Response 
register. 

RULE C.3.4: 

IF a word serial data transfer requires more than a single bus cycle, 

THEN the least significant byte must be transferred last, to ensure validity of the associated Read Ready or 
Write Ready bit. 

RULE C.3.5: 

All Message Based Devices SHALL always respond to the Word Serial protocol. 


C.3.3.1.2 Longword Serial Transfers 

The longword serial transfer is a higher performance protocol than the word serial, having a 32-bit wide data 
path. 

Data is transferred by reads or writes of the Data High and Data Low registers. By default, all writes are 
interpreted as commands. Each Longword Serial transfer affects the state of the appropriate bit (Read Ready 
or Write Ready) of the Response register. 

RULE C.3.6: 

IF a longword serial data transfer requires more than a single bus cycle, 

THEN the least significant word or byte must be transferred last, to ensure validity of the associated Read 
Ready or Write Ready bit. 

OBSERVATION C.3.6: 

Support of the Longword Serial communication protocol is optional for Message Based Devices. This 
capability is indicated in the response to the read protocol command (see Section E.l, "Word Serial 
Commands"). 
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C.3.3.1.3 Extended Longword Serial Transfers 

The extended longword serial transfer is a higher performance protocol than the longword serial, having a 
48-bit wide data path. This is a write only protocol. 

Data is transferred by writes to the Data Extended, Data High and Data Low registers. By default, all writes 
are interpreted as commands. Each Extended Longword Serial transfer affects the state of the Write Ready bit 
of the Response register. 

RULE C.3.7: 

IF an extended longword serial data transfer requires more than a single bus cycle, 

THEN the least significant word or byte must be transferred last, to ensure validity of the associated Read 
Ready or Write Ready bit. 

PERMISSION C.3.2: 

Support of the Extended Longword Serial communication protocol is optional for Message Based Devices. 
This capability is indicated in the response to the read protocol command (see Section E.l, "Word Serial 
Commands"). 


C.3.3.2 FAST HANDSHAKE TRANSFERS 

The word serial protocols may utilize either of two handshake modes for data transfer, the Normal Transfer 
mode or the Fast Handshake mode. In the normal transfer mode, a Commander uses bits in the Servant's 
Response register to synchronize data transfers. In the East Handshake mode, a Commander is allowed to 
execute word serial data transfers without checking the Servant's Response register. 

The East Handshake mode uses the Servant's DTACK* and BERR* lines to enforce proper synchronization. 
In this mode, a Servant may hold off a VMEbus transfer for up to 20 ps until it is ready to complete the 
transaction. If the 20 ps expires before the appropriate readiness condition is true, the Servant will assert 
BERR*. Otherwise the Servant will assert DTACK* and complete the transfer normally. 

When in the East Handshake mode, a Servant is always ready to accept certain defined word serial operafions. 
These operafions are defined by higher-layer protocols such as fhe Byfe Transfer protocol (See Secfion C.3.3.3, 
"Byfe Transfer Protocol"). In fhe Easf Handshake mode a Commander is allowed fo send cerfain sfandard 
word serial commands which may be fransmiffed using eifher Normal Handshake or Easf Handshake mefhods. 
These are referred fo as FHS Commands. 

RULE C.3.8: 

A Commander SHALL NOT affempf any word serial operafions using fhe Easf Handshake profocol, unless 
such operafions are execufed wifhin fhe confexf of a higher-layer profocol using only fhe EHS commands 
defined for fhaf profocol. 

OBSERVATION C.3.7: 

Presenfly, fhe only defined EHS commands are fhe Byte Available and Byte Request commands used in fhe 
Byfe Transfer Profocol. Eufure VXIbus specifications may define additional EHS commands. 
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C.3.3.2.1 Servant Fast Handshake Operation 

RULE C.3.9: 

A Message Based Servant SHALL always support the normal transfer mode, even when in the Fast Handshake 
mode. 

OBSERVATION C.3.8: 

A FHS capable Servant supports the normal transfer mode by always indicating its true state via the Write 
Ready, Read Ready, DIR, DOR and Err* bits in its Response register. 

PERMISSION C.3.3: 

When in the Fast Handshake mode, a Servant MAY set any of its Write Ready,Read Ready, DIR or DOR bits in 
its Response register to one (1), up to 20 //s before the indicated condition becomes true. 

RECOMMENDATION C.3.1: 

When in Fast Handshake mode, a Servant should control its Response register bits in a manner that allows 
normal mode transfers to execute without long VMEbus data transfer cycles. 

A Servant indicates its support of the Fast Handshake mode via the FHS* bit in its protocol register. The FHS 
Active* bit of its Response register indicates the current status of the Servant's Fast Handshake mode. The 
meanings of these bits are summarized in the following table. 


BIT 

Value 

0 1 

FHS* 

Capable 

Incapable 

FHS Active* 

Active 

Inactive 


PERMISSION C.3.4: 

A Servant MAY initiate the Fast Handshake mode by clearing the FHS Active* bit, at a time defined by the 
applicable higher-layer protocol. 

Because a Commander in the Fast Handshake mode does not test the Read Ready and Write Ready bits, a FHS 
capable Servant is required to prevent incorrect data transfers by asserting BERR*. Such incorrect transfers 
may be caused by Read Ready protocol violations. Write Ready protocol violations, higher-layer protocol 
violations or the Servant's inability to keep up with the Commander's data flow rate, either before or after the 
Servant has exited the EHS active mode. 

RULE C.3.10: 

A East Handshake capable Servant SHALL assert BERR* if it cannot complete a data transfer cycle accessing 
its Data Low register within 20 //s. 

RECOMMENDATION C.3.2: 

When a East Handshake capable servant cannot complete a Data Low register transfer immediately, but can 
complete the transfer within 20 //s, the Servant should assert RETRY*. 

RECOMMENDATION C.3.3: 

A East Handshake capable Servant should not continue to respond with RETRY* assertions to successive 
accesses for more than 20 //s. 

A Servant may terminate the East Handshake mode at any time by setting (to 1) its FHS Active* bit. It will 
assert BERR* on the next read or write of the Data Low register that it cannot complete within 20 //s. 

A Servant will terminate the East Handshake mode any time it asserts BERR* during a data transfer cycle. 
Under this condition, the Servant updates neither its read nor write queue. It sets (to I) its FHS Active* bit and 
operates in the normal transfer mode until it is ready to resume the East Handshake mode. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 




Page 182 


Section C: System Architecture 


C.3.3.2.2 Commander Fast Handshake Operation 

The Fast Handshake mode is optional for Commanders, since the normal transfer mode always functions 
properly. This is true even if its Servant is in the Fast Handshake mode, because its Response register 
indications are always correct. 

A Commander that supports the Fast Handshake mode may execute Fast Handshake transfers only with 
Servants that are capable of Fast Handshake transfers and which have the Fast Handshake mode active. 

RULE C.3.11: 

A Commander SHALL NOT attempt Fast Handshake mode operations with a Servant having the FHS* bit of 
its protocol register set (to one). 

RULE C.3.12: 

A Commander SHALL NOT attempt Fast Handshake operations with a Servant while the Servant's FHS 
Active* hit is set (to 1). 

A Commander may begin Fast Handshake transfers with a capable Servant only as provided for by the 
operating higher-layer protocol (provided that the Servant's FHS Active* bit is asserted (0)). It may exit the 
fast handshake mode at any time. However, it must exit the Fast Handshake mode after any data transfer 
attempt that results in a bus error or at any other time defined by the higher-layer protocol. The Fast 
Handshake mode must not be resumed until the Servant again clears (to 0) its FHS* Active bit. 

RULE C.3.13: 

IF a word serial data transfer attempt to a Fast Handshake capable Servant results in the assertion of 
BERR*, 

THEN the Commander SHALL NOT attempt any Fast Handshake transfers with the same Servant until that 
Servant clears (to 0) its FHS Active* bit. 

OBSERVATION C.3.9: 

No data is transferred during a cycle that causes a bus error. The failed transfer should be retried. 

OBSERVATION C.3.10: 

Once a Commander detects a Servant in the Fast Handshake active condition, it does not need to check the 
Servant's Read Ready, Write Ready, DIR, DOR, Err* or FHS Active* bits again until the Commander exits the 
Fast Handshake mode. 


C.3.3.3 WORD SERIAL DATA TRANSFER PROTOCOLS 

Word serial commands can be used to transfer data between commanders and their servants. The Byte 
Transfer Protocol is described in this specification. Other data transfer protocols may also be defined. Word 
serial data transfer protocols operate by a commander sending commands and queries to its servant. Data sent 
to the servant is embedded in the commands. Data from Servants is sent in response to queries. It is possible 
to define profocols fhaf do nof require fhaf dafa senf fo servanfs be embedded in commands or fhaf dafa from 
servanfs be senf only in response fo queries. However, such protocols are nof allowed to interfere wifh a 
servanf device's ability to receive normal Word Serial commands and queries. A servanf device may support 
mulfiple dafa Iransfer protocols. Generally, only dafa Iransfer protocol may be acfive af any one lime. 

Dafa flow can be regulated by Ihe DIR and DOR bils of Ihe servanl's response regisler. The DIR bil indicates 
fhaf Ihe servanf is ready to accepl dafa from Ihe commander. The DOR bil indicates fhaf Ihe servanf has dafa 
available for Ihe commander. These bils may be used by mulfiple dafa Iransfer protocols. 
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RULE C.3.14: 

A servant device SHALL NOT implement a data transfer mode that prevents that device from correctly 
processing normal word serial commands. 

OBSERVATION C.3.11: 

An example of a mode prohibited by the preceding rule is one in which all Word Serial commands are 
interpreted as data. A device in this mode would be unable to respond to commands such as Clear. 


C.3.3.3.1 Byte Transfer Protocol 

The Byte Transfer Protocol is a mechanism for transferring 8-bit data between Commanders and their 
Servants. It utilizes the word serial Byte Available and Byte Request commands. The Byte Available command 
is used to transfer data from a Commander to its Servant. The Byte Request command is used to transfer data 
from a Servant to its Commander. The data flow is regulated by the use of the DIR and DOR bits in the 
Servant's Response register. 

RULE C.3.15: 

When a Message Based Servant using the Byte Transfer Protocol is not ready to process a Byte Available 
command it SHALL clear to zero (0) the DIR bit in its Response register. 

OBSERVATION C.3.12: 

When a Message Based Servant using the Byte Transfer Protocol is ready to process a Byte Available 
command it will set to one (1) the DIR bit in its Response register. 

RULE C.3.16: 

When a Message Based Servant using the Byte Transfer Protocol is not ready to process a Byte Request 
command, it SHALL clear to zero (0) the DOR bit in its Response register. 

OBSERVATION C.3.13: 

When a Message Based Servant using the Byte Transfer Protocol is ready to process a Byte Request command, 
it will set to one (1) the DOR bit in its Response register. 

RULE C.3.17: 

IF a word serial command to a Message Based Servant using the Byte Transfer Protocol causes the 
unassertion of the DIR bit, 

THEN the Write Ready bit SHALL NOT be set to one (1) until the DIR bit is cleared to zero (0). 

RULE C.3.18: 

IF a word serial command to a Message Based Servant using the Byte Transfer Protocol causes the 
de-assertion of the DOR bit, 

THEN the Write Ready bit SHALL NOT be set to one (1) until the DOR bit is cleared to zero (0). 

RULE C.3.19: 

A Servant using the Byte Transfer Protocol SHALL NOT clear (to 0) either its DIR or DOR bit while its Write 
Ready bit is set (to 1). 

RULE C.3.20: 

A Commander executing the Byte Transfer Protocol with a Servant SHALL NOT send a Byte Available 
command to that Servant while its DIR bit is cleared to zero (0). 

RULE C.3.21: 

A Commander executing the Byte Transfer Protocol with a Servant SHALL NOT send a Byte Request 
command to that Servant while its DOR bit is cleared to zero (0). 
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C.3.3.3.1.1 FAST HANDSHAKE SUPPORT 

The Byte Transfer Protocol may be executed using the Fast Handshake protocol. Both the Byte Available and 
the Byte Request commands are FHS commands, which may utilize the Fast Handshake protocol. 

RULE C.3.22: 

A Servant using the Byte Transfer protocol and the Fast Handshake protocol SHALL support Fast Handshake 
transfers of both the Byte Available and Byte Request commands. 


C.3.3.3.1.1.1 Byte Available 

The FHS protocol may be used to transfer a message using a series of Byte Available commands. A Servant 
capable of receiving Byte Available commands in the Fast Handshake mode may enter the FHS Active state 
(and assert its FHS Active* bit) if it is ready to receive Byte Available commands using the Fast Handshake 
protocol. 

A Commander may begin using Fast Handshake transfers to send Byte Available commands to a Servant if the 
Servant's Write Ready, DIR and ERR* bits are set to one and the FHS Active* hit is asserted (0). 

RULE C.3.23: 

A Commander SHALL NOT begin Fast Handshake transfers of Byte Available commands to a Servant if that 
Servant's DIR bit is zero (0) or its Write Ready bit is zero (0) or its Err* bit is zero (0) or its FHS Active* bit is 
one (1). 

RULE C.3.24: 

A Commander using Fast Handshake to transfer Byte Available commands to a Servant SHALL exit the Fast 
Handshake mode before sending any command other than Byte Available to that Servant. 

OBSERVATION C.3.14: 

A Commander is required to exit the Fast Handshake mode when a read or write of the Servant's Data Low 
register results in a bus error. 

The END bit of the Byte Available command is used to indicate the end of a message. This may cause a 
servant to exit the Fast Handshake Active state. If the commander also exits the Fast Handshake mode, it can 
avoid a bus error. 

RECOMMENDATION C.3.4: 

A Commander should exit the Fast Handshake mode after sending a Byte Available command having the END 
bit asserted. 

RULE C.3.25: 

When its Commander writes a Byte Available to a Servant capable of receiving Byte Available commands in 
the Fast Handshake mode and the Servant's DIR bit is zero, the Servant SHALL assert BERR* without 
changing the state of any of its Read Ready, Write Ready, DIR, DOR or Err* bits. 


C.3.3.3.1.1.2 Byte Request 

The EHS protocol may be used to transfer a message using a series of Byte Request commands. A Servant 
capable of receiving Byte Request commands in the East Handshake mode may enter the EHS Active state (and 
assert its EHS Active* bit) if it is ready to receive Byte Request commands using the East Handshake protocol. 

A Commander may begin using East Handshake transfers to send Byte Request commands to a Servant if the 
Servant's Write Ready, DOR and ERR* bits are set to one and the FHS Active* bit is asserted (0). 
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RULE C.3.26: 

A Commander SHALL NOT begin Fast Handshake transfers of Byte Request commands to a Servant if that 
Servant's DOR bit is zero (0) or its Write Ready bit is zero (0) or its Err* bit is zero (0) or its FHS Active* bit is 
one (1). 

RULE C.3.27: 

A Commander using Fast Handshake to transfer Byte Request commands to a Servant SHALL exit the Fast 
Handshake mode before sending any command other than Byte Request to that Servant. 

OBSERVATION C.3.15: 

A Commander is required to exit the Fast Handshake mode when a read or write of the Servant's Data Low 
register results in a bus error. 

The END bit of the response to a Byte Request command is used to indicate the end of a message. This may 
cause a servant to exit the Fast Handshake Active state. If the commander also exits the Fast Handshake mode, 
it can avoid a bus error. 

RECOMMENDATION C.3.5: 

A Commander should exit the Fast Handshake mode after reading a response to a Byte Request command if the 
END bit of the response is asserted. 

RULE C.3.28: 

When its Commander writes a Byte Request to a Servant capable of receiving Byte Request commands in the 
Fast Handshake mode and the Servant's DOR bit is zero, the Servant SHALL assert BERR* without changing 
the state of any of its Read Ready, Write Ready, DIR, DOR or Err* bits. 


C.3.3.4 ERROR HANDLING 

VXIbus Message Based Devices implement a uniform method of reporting word serial protocol errors. It is a 

multi-level approach wherein all word serial protocol conformance errors are reported via the Err* bit in the 

Response register and the Read Protocol Error command. Higher level errors are reported at higher levels, 

often as status responses to commands. 

There are six defined word serial protocol errors: 

Unsupported Command: This error is detected when a Servant receives a command which it does not 
support. 

Multiple Query: This error occurs when a Servant receives a command requiring it to output a response to its 
Data Low register and is unable to respond because of an unread response to a previous command. 

DIR Violation: This error occurs when a Servant receives a Byte Available command when it is unable to 
process that command because the DIR bit is zero (0). 

DOR Violation: This error occurs when a Servant receives a Byte Request command when it is unable to 
process that command because the DOR bit is zero (0). 

Write Ready Violation: This error occurs when data is written to a Servant while its Write Ready bit is zero 

( 0 ). 

Read Ready Violation: This error occurs when data is read from a Servant while its Read Ready bit is zero 

( 0 ). 
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RULE C.3.29: 

A Message Based Device SHALL detect the Unsupported Command, Multiple Query, DIR Violation and DOR 
Violation errors. 

OBSERVATION C.3.16: 

A Servant may respond to a Read Ready or Write Ready protocol violation by either asserting BERR*, 
asserting its Err* bit or not detecting the violation. 

OBSERVATION C.3.17: 

A East Handshake capable Servant prevents incorrect data transfers due to DIR and DOR violations by 
asserting RETRY* or BERR*. 

RULE C.3.30: 

IF a command to a Message Based Device causes the detection of one of the defined word serial protocol 
errors, 

THEN the device SHALL NOT execute that command. 

RULE C.3.31: 

IF a command to a Message Based Device causes the detection of one of the defined word serial protocol 
errors which does not result in a bus error, 

THEN the Servant SHALL clear both the Err* and Read Ready bits. The Write Ready bit SHALL NOT be 
set to one (1) until both the Err* and Read Ready bits are cleared to zero (0). 

RULE C.3.32: 

Each Message Based Device SHALL maintain its Current Error State (which is reported via the Read 
Protocol Error command) as follows: 

1. The current error state is set to No error by a HARD RESET, SOET RESET or receipt of the Clear 
command. 

2. The current error state is set to No error when the device responds to the End Normal Operation or the 
Abort Normal Operation command. 

3. The current error state is set to No error after the device responds to the Read Protocol Error command. 

4. When a word serial protocol error is detected while the device is in the No Error state, the current error 
state is set to reference that error. Subsequent errors SHALL NOT cause updates to the error state. 

RULE C.3.33: 

When a Message Based Servant receives the Read Protocol Error command, it SHALL set its Err* bit to one 
(1) before it sets its Write Ready bit to one (1). 

OBSERVATION C.3.18: 

A Commander that implements rigorous error checking will test for errors after writing each command as 
follows: 

1. Wait for the Write Ready bit to be asserted. 

2. Test the Err* bit. 

3. If no error is indicated, then read the response data (when Read Ready is asserted) or send the next 
command. Otherwise, send Read Protocol Error and read its response. 
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RECOMMENDATION C.3.6: 

Commanders and Resource Managers should implement rigorous error checking when communicating with 
their Servants, especially during system initialization. 

RULE C.3.34: 

When a Message Based Servant receives a command requiring it to output a response to its data low register, it 
SHALL NOT make the re-assertion of its Write Ready bit contingent on its Commander reading the response 
data. 


C.3.3.5 DEVICE FAILURES 

When a device experiences a catastrophic failure, it enters the FAILED state, asserting SYSFAIL* and clearing 
(to 0) its Passed bit. 

RULE C.3.35: 

IF a device is in the FAILED state, 

THEN that device's Commander SHALL set (to I) the Sysfail Inhibit bit of the Control register on the failed 
device. 

PERMISSION C.3.5: 

When a device fails, the device's Commander MAY also set (to 1) the Reset bit of the Control register on the 
failed device. 

OBSERVATION C.3.19: 

A Commander may detect that a Servant has failed by monitoring the SYSFAIL* signal or polling the Passed 
bit in the Status register of a device. 

RECOMMENDATION C.3.7: 

When a top level device fails, the Resource Manager should set (to 1) the Sysfail Inhibit bit of the Control 
register on the failed device. 
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C.4 SYSTEM RESOURCES 

The VXIbus architecture provides for a set of common system resources. These include Slot 0 services and 
system configuration management. This section describes how these services are provided. The configuration 
management services are provided by a central Resource Manager and Slot 0 services are either provided by 
the Resource Manager or by Slot 0 devices. 


C.4.1 Resource Manager 

The VXIbus Resource Manager is a device at Logical Address 0 that performs the following functions at 
system power-on. 

1. Identify all VXIbus devices in the system. 

2. Manage the system self test and diagnostic sequence. 

3. Configure the system's A24, A32 and A64 address maps. 

4. Configure the system's Commander/Servant hierarchies. 

5. Allocate the VMEbus IRQ lines. 

6. Initiate normal system operation. 

The logical addresses of VXIbus devices can be statically set or dynamically assigned. In this section, the 
Resource Manager's functions in the case of statically set logical addresses are described. The functions for 
dynamic assignment of logical addresses are described in Section F, "Dynamic Configuration". 

RULE C.4.1: 

A Resource Manager SHALL be a Message Based Device with Commander capability. 

PERMISSION C.4.1: 

The functions of a Resource Manager MAY be combined with those of another Message Based Commander. 

OBSERVATION C.4.1: 

If a Resource Manager is combined with other Message Based functionality, the Resource Manager configures 
its Message Based functions as it would any other Message Based Device. In this case it uses device specific 
internal communications, instead of word serial commands. 

RULE C.4.2 

IF a Resource Manager device is not configured as a top level Commander, 

THEN it SHALL behave as a normal Message Based Device toward its Commander and Servants. 

RULE C.4.3: 

A Resource Manager SHALL provide a device specific mechanism for reporting system configuration errors. 

PERMISSION C.4.2: 

A Resource Manager MAY provide Slot 0 services in addition to its other duties. 

RULE C.4.4: 

A Resource Manager which lacks device specific knowledge of a device SHALL write a one (1) to all the 
device dependent bits in the Control register whenever it writes to the Control register of that device. 

OBSERVATION C.4.2: 

A Resource Manager will normally write to the Control register of a device to affect the A24/A32/A64 Enable, 
Sysfail Inhibit or Reset bits. 
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C.4.1.1 DEVICE IDENTIFICATION 

The Resource Manager identifies the available VXIbus devices according to the following procedure. 

RULE CAS: 

All Resource Managers SHALL implement the following device identification procedure. 

1. After the unassertion of SYSRESET*, wait until either SYSEAIL* is unasserted or five seconds (5.0 s) 
have elapsed (whichever occurs first) before accessing any other VXIbus device's A16 configuration 
registers. 

2. Attempt a read of the Status register at each of the 256 defined configuration register locations. If an 
attempt is successful, the corresponding device is present. If a bus error results, the device is absent. 

OBSERVATION C.4.3: 

Local VMEbus operations that do not access any of the registers of VXIbus devices are permitted before the 

unassertion of SYSEAIL* or the five (5) second timeout. 


C.4.I.2 SYSTEM SELF TEST MANAGEMENT 
RULE CA6: 

All Resource Managers SHALL implement the following self test management procedure. 

1. Wait until all self tests have completed. 

2. Eorce all failed devices into the SOET RESET state with SYSEAIL* assertion inhibited (see Section 
C.2.I.2, "Device Initialization and Diagnostics"). 

OBSERVATION C.4.4: 

A device has completed its self test when its Passed bit is one (1) or when at least five seconds after power-on 
(Unassertion of SYSRESET*) have elapsed. 

OBSERVATION C.4.5: 

The Resource Manager forces a device into its SOET RESET state by writing a one to the device's Reset bit. 

OBSERVATION C.4.6: 

The Resource Manager causes a device to inhibit SYSEAIL* assertion by writing a one to the device's Sysfail 
Inhibit bit. 

PERMISSION C.4.3: 

A Resource Manager MAY perform diagnostic tests of a failed device by some device dependent method. 

PERMISSION C.4.4: 

A Resource Manager MAY implement the capability to detect the subsequent failure of a device that has 
passed its initial self test. 

RULE C.4.7: 

When the Resource Manager detects that a device has failed sometime after the initial five seconds but before 
the Resource Manager has sent the Begin Normal Operation command to that device's top-level Commander, 
the Resource Manager SHALL force the failed device into the SOET RESET state with SYSEAIL* assertion 
inhibited. 
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C.4.1.3 ADDRESS MAP CONFIGURATION 
RULE CAS: 

All Resource Managers SHALL implement the following A24, A32 and A64 address map configuration 
procedure: 

1. Determine which devices implement A24, A32 or A64 registers by reading the Address Space field of 
each device's ID register and the Address Mode field of the Enhanced Capabilities register, if appropriate. 

2. Determine the number of A24, A32 or A64 registers implemented by each device by reading the 
Required Memory field of the device's Device Type register. 

3. Calculate A24, A32 and A64 offsets such that no two device's address spaces overlap. 

4. Assign the A24, A32 and A64 base addresses by writing the offsets to each device's Offset register. 

5. Enable each device's A24, A32 or A64 registers by writing a one (1) to the A24/A32/A64 Enable bit of 
each device's Control register. 

RECOMMENDATION C.4.1: 

All A24 base address offsets should be assigned so that the registers are placed within the address range 
2 OOOOO 16 through DEEEEE 16 . All A32 base address offsets should be assigned so that the registers are placed 
within the address range 20000000i6 through DEEEEEEEig. 

RECOMMENDATION C.4.2: 

Eor compatibility with possible future versions of the VXIbus Specification, Resource Managers should be 
designed to properly configure any A16 Only, A16/A24 or A16/32 device that implements an Enhanced 
Capability register. Such a device would have the value IO 2 in the Address Space field of its ID register. In 
this case, a Resource Manager should use the value in the Address Mode field of the Enhanced Capability 
register to determine the address modes used by the device, according to the following table: 

Value Mode 
000 A16/A24 

001 A16/A32 

Oil AlhOnly 

OBSERVATION C.4.7: 

All A16 Only, A16/A24 and A16/A32 devices are now required to report their addressing modes in the 
Address Space field of the ID register. Euture versions of the VXIbus Specification may define additional 
capabilities that would be indicated in the Enhanced Capability register. An A16 Only, A16/A24 or A16/A32 
device that implements such capabilities would have the value IO 2 in the Address Space field of its ID register. 
Its addressing modes would then have to be reported in the Address Mode field of its Enhanced Capabilities 
register. The preceding recommendation anticipates this situation. 


C.4.I.4 COMMANDER/SERVANT HIERARCHIES 

The Resource Manager establishes a system wide control hierarchy. This structure has the form of one or more 
inverted trees. The hierarchical relationships are described by the terms Commander and Servant. A 
Commander is any device in the hierarchy with one or more associated lower level devices. A Servant is any 
device in the subtree of a Commander. A device may be both a Commander and a Servant in a multiple level 
hierarchy. A Commander has exclusive control of his immediate Servants' communication and control 
registers. A top level Commander has no Commander but may have Servants. All Commanders are Message 
Based Devices. 

A Resource Manager establishes the system hierarchy in the following manner. 

1. Eind all Commanders by checking the CMDR bit in the protocol register of each Message Based Device. 

2. Read the Servant Area Size from each Commander, using the Read Servant Area query. 
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3. Determine the Commander/Servant hierarchies. 

4. Assign Servants to Commanders, using the grant device command. 

RULE C.4.9: 

A Resource Manager SHALL implement some means of building a Commander/Servant hierarchy. 

RECOMMENDATION C.4.3: 

A Resource Manager should implement the default Commander/Servant mapping algorithm described in the 
following section. 

OBSERVATION C.4.8: 

Each Commander maintains a list of its Servants, received via the grant device command. It maintains this list 
until the next activation of HARD RESET or SOET RESET or the receipt of the Abort Normal Operation 
command. 

RULE C.4.10: 

A Resource Manager SHALL NOT grant to any Commander a device which the Resource Manager knows to 
be in any state other than PASSED, (see Section C.2.1.2.2, "Self Test Operation"). 

OBSERVATION C.4.9: 

It cannot be assured that the Resource Manager will detect any device failures after the initial self test. 


C.4.1.4.1 Commander/Servant Mapping 

The default Commander/Servant mapping algorithm allows for a virtually unlimited number of hierarchical 
levels. It is based on each VXIbus device's Logical Addresses and each Commander's Servant are A-sized. 
The Servant are A-size is an 8-bit (0-255) value selected by the user or at the factory. It is stored in a non¬ 
volatile fashion in each Commander device. 

A Commander's Servant area starts at the next consecutive Logical Address after the Commander's logical 
address and includes the number of contiguous Logical Addresses given by the Commander's Servant are 
A-size. 

If a device is in the Servant area of a given Commander and it is not in the Servant area of any other device 
within that Commander's Servant area, then it is a Servant of that Commander and may be assigned to that 
Commander by the Resource Manager. 

OBSERVATION C.4.10: 

All of a device's default Servants are in its own Servant area. 

OBSERVATION C.4.11: 

A device's Servant area may include the Servant areas of its Servants. 

OBSERVATION C.4.12: 

None of a device's Servants are located in any of the Servant areas of its Servants. 


C.4.1.5 ALLOCATION IRQ LINES 

The Resource Manager is responsible for allocating the VMEbus IRQ lines among the various Interrupt 
Handlers and Interrupters in the system. Each IRQ line may be assigned to only one handler, but to several 
Interrupters. Provision must be made for devices with jumper selectable IRQ line assignments as well as for 
programmable Interrupters and Interrupt Handlers. This requires that some interrupt configuration information 
be supplied by the system user. 

RULE C.4.11: 

A Resource Manager SHALL provide a means for a user to supply interrupt configuration information relating 
Interrupt Handlers and Interrupters to any or all interrupt lines. 
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OBSERVATION C.4.13: 

The form of the interrupt configuration information is device dependent. It is anticipated that the information 
will typically be loaded from a system console, downloaded from a host computer or retrieved from some form 
of non-volatile storage. 

RULE C.4.12: 

A Resource Manager SHALL allocate IRQ lines to Interrupt Handlers according to the following procedure. 

1. Determine which Message Based Devices support Programmable Interrupt Handler (PH) capability 
(using the Read Protocol command). 

2. Allocate the IRQ lines according to the following rules: 

a. First use the supplied interrupt allocation information. 

b. Then allocate one of the remaining IRQ lines to each PH capable Commander, in any desired order. 

c. Finally allocate any remaining IRQ lines to any Servant-only PH capable Message Based Devices, 
and any PH Commanders indicating multiple handler capability. 

3. For each Programmable Handler assigned an IRQ line, program its IRQ allocation, using the Read 
Handlers, Read Handler Line and Assign Handler Line commands. 

RULE C.4.13: 

A Resource Manager SHALL allocate IRQ lines to Interrupters according to the following procedure. 

1. Determine which Message Based Servants have Programmable Interrupter (PI) capability, using the Read 
Protocol command. 

2. Allocate the IRQ lines according to the following rules: 

a. First use the supplied interrupt allocation information. 

b. Then allocate an IRQ line to each PI capable Servant, based on its Commander's IRQ line 
allocation. 

3. For each Programmable Interrupter assigned an IRQ line, program its IRQ allocation, using the Read 
Interrupters, Read Interrupter Line and Assign Interrupter Line commands. 


C.4.1.6 INITIATING NORMAL OPERATION 

After allocating IRQ lines, a Resource Manager may provide some system dependent start-up services. It then 
sends the Begin Normal Operation command, with the Top Level bit set (to one (I)), to all top level 
Commanders in order of increasing logical address. At this point the Resource Manager's power-on sequence 
is complete and it may enter its run time operating mode. 

Each top level Commander is then required to initialize its Servants. Each Commander must send the Begin 
Normal Operation command, with the Top Level bit cleared (to zero (0)), to all of its Message Based Servants. 
Therefore, the Begin Normal Operation command propagates down the hierarchy from Commanders to 
Servants, until all Message Based Devices have received it. 

RULE C.4.14: 

A Resource Manager SHALL NOT change the configuration or state of any other device's Servant from its 
power-on default conditions, except as required to perform the system self test management, address map 
configuration, commander/servant mapping, IRQ line allocation and dynamic Logical Address assignment. 

OBSERVATION C.4.14: 

When a Commander receives the Begin Normal Operation command, its Message Based Servants are in the 
CONEIGURE sub-state with any Response and Event generation capabilities set according to the default 
configuration defined in Rule C.2.78. 
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C.4.2 Runtime Resource Management 

In Section C.4.1, "Resource Manager" and in Section F, "Dynamic Configuration", resource management is 
defined only for defaulf configuration. The behavior of a Resource Manager which provides ongoing services 
for a device in NORMAL OPERATION sub-slafe has nol been defined. Ongoing resource managemenf 
services can be used fo supporf shared resource utilization or olher syslem operalions. In Ihe following, Ihe 
lerm "runtime resource managemenf" is used for such ongoing resource managemenf. 

PERMISSION 0.4.5: 

A Resource Manager which handles defaulf syslem configuralion as described in Section C.4.1, "Resource 
Manager" (and in seclion F, "Dynamic Configuration") MAY handle runlime resource managemenf. 

OBSERVATION C.4.15: 

If is a violation of Ihe Word Serial Protocol for a device involved in runtime resource managemenf to send any 
word serial command (including End Normal Operation and Abort Normal Operation) to any device while lhal 
device's Commander is in Ihe NORMAL OPERATION sub-slale. 

C.4.3 VXIbus Subsystem Slot 0 

A VXIbus Slol 0 device provides common resources to ils VXIbus subsystem slols 1-12. On P2, Ihe resources 
provided are CLKIO and MODID. On P3, Ihe Slol 0 device provides CLKIOO. Il may also provide 
SYNC 100, STARX and ST ARY signal dislribulion on P3. 

OBSERVATION C.4.16: 

VXIbus Slol 0 devices exisl only on B, C and D form factors. 

RULE C.4.15: 

All Slol 0 devices SHALL supply CLKIO. 

RULE C.4.16: 

All Slol 0 devices SHALL supporl MODID. 

RULE C.4.17: 

All P3 Slol 0 devices SHALL provide CLKIOO. 

OBSERVATION C.4.17: 

SYNClOO, STARX and ST ARY are nol required to be supported by Slol 0 devices. 

RECOMMENDATION C.4.4: 

If only one STAR signal sel is provided, il should be STARX. 

RECOMMENDATION C.4.5: 

IF a Slol 0 device supports eilher STAR signal sel 
THEN il should supporl a contiguous sel of slols including slol 1. 

OBSERVATION C.4.18: 

A Slol 0 device is only guaranteed to provide CLKIO and MODID supporl. Il may also provide olher services 
such as SYNClOO arbilration, Irigger line buffering and STARX and ST ARY routing. 

A Slol 0 device may be identified by ils Model Code, which has a value in Ihe range 0 —> 255 (Oie —> FFig). 

RULE C.4.18: 

All VXIbus Slol 0 devices SHALL have model codes m Ihe range 0^5 ^ FFjg. 

RULE C.4.19: 

A VXIbus device which is nol enabled for Slol 0 funclionalily SHALL NOT have a model code in Ihe range 
0i6 — > FFi6. a Slol 0 device wilh ils Slol 0 functions disabled (via swilches, jumpers, cul Iraces, elc) SHALL 
also have ils Model Code modified to some value oulside Ihe range Oie —> FFig. 


RECOMMENDATION C.4.6: 
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A Slot 0 module's Slot 0 and VMEbus system controller capability should be defeatable in order to allow that 
module to be placed in any slot position. 

RULE C.4.20: 

All MODID drivers SHALL be disabled by both hard and soft resets (See Section C.2.1.2.2, "Self Test 
Operation"). 


C.4.3.1 REGISTER BASED SLOT 0 DEVICES 

A Register Based Slot 0 Device is a standard VXIbus Register Based Device that supports Slot 0 functionality. 
Its Model Code (in its Device Type register - See Section C.2.1.1.2, "Configuration Registers") is in the range 
0 —> 255 (0i6 —> FFjg) and it has a MODID register at its AI6 base address + Sie. It may implement additional 
Slot 0 related registers. 

RULE C.4.21: 

A Register Based VXIbus Slot 0 Device SHALL implement a MODID register as defined in the following 
section (C.4.3.1.1) at its A16 base address + Sie, 

PERMISSION C.4.6: 

The remaining device dependent registers MAY be used to implement other Slot 0 related services. 


C.4.3.1.1 MODID Register 

The MODID register indicates the status of and provides control of the associated MODID lines. It conforms 
to the following format. 


Bit# 

15 ^ 14 

13 

12^0 

Contents 

RESERVED 

Output 

Enable 

MODIDOO-12 


The fields of the MODID register are defined below. 

• RESERVED: This field is reserved for future VXIbus definition. A write to this field has no effecl. A 
read of fhis field refurns all ones (Sie). 

• Oufpuf Enable: Wrifing a one (1) fo fhis bif enables fhe Slof 0 MODID drivers. Writing a zero (0) fo fhis 
bif disables fhe MODID drivers. A one (I) read from fhis bif indicates fhaf fhe MODID drivers are 
enabled. A zero (0) indicates fhaf fhe drivers are disabled. 

OBSERVATION C.4.19: 

All MODID drivers are disabled by device resefs (The Output Enable bif is cleared (fo 0)). 

• MODID 00-12: Writing a one (I) fo any of fhese bifs drives fhe corresponding MODID line high, if fhe 
Output Enable bif is sef. Wrifing a zero (0) fo any of fhese bifs drives fhe corresponding line low, if fhe 
Output Enable bif is sef. When read, each of fhese bifs indicates fhe acfual level of fhe corresponding 
MODID line (1 = HI, 0 = LOW). 

OBSERVATION C.4.20: 

Affer sysfem power up, fhe bif values of MODIDOO-12 in fhe MODID wrife regisfer may be undefined. 


C.4.3.2 MESSAGE BASED SLOT 0 DEVICES 
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A Message Based Slot 0 Device is a standard VXIbus Message Based Device that supports Slot 0 
functionality. Its Model Code (in its Device Type register - See Section C.2.1.1.2, "Configuration Registers") 
is in the range 0 —> 255 and it supports the MODID related commands. It may implement additional Slot 0 
related commands. 

RULE C.4.22: 

A Message Based VXIbus Slot 0 Device SHALL implement the Read MODID, Set Lower MODID and Set 
Upper MODID commands as defined in Section E.l, "Word Serial Commands". 

PERMISSION C.4.7: 

A Message Based Slot 0 Device MAY implement commands to provide other Slot 0 related services. 

The MODID related commands are used to indicate the status of the MODID lines and to control the levels of 
the MODID lines. 

OBSERVATION C.4.21: 

All MODID drivers are disabled by device resets. 


C.4.3.3 OTHER SLOT 0 DEVICES 

Since VXIbus only requires support of MODID and CLKIO lines from a Slot 0 device, the Resource Manager 
may provide the Slot 0 services in addition to its other functions. This arrangement hides the Slot 0 
functionality inside the Resource Manager and therefore allows another device to provide Slot 0 functionality 
without using a Logical Address for a minimal Slot 0 implementation. 
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D. VXIbus DEVICE IMPLEMENTATIONS 


This section describes the design rales for certain devices which facilitate manufacturer to manufacturer 
interchangeability. The protocols are defined at a higher level than defined by the system architecture. These 
protocols, along with the common command formats, are specified in the following sections. 

One common device is a VXIbus to IEEE 488 bus interface. This device allows VXIbus devices to be 
controlled via the 488 bus as if they are 488 devices. The following sections define such an interface, its 
VXIbus protocols and the requirements for an instrument to interface to it. The protocols are intended to be 
extensible to other interfaces and Commanders. 


D.l VXIbus INSTRUMENTS 

This section specifies the interfacing requirements for VXIbus Instruments. These are devices which may be 
controlled with the VXIbus In s trument Protocol, implemented by a VXIbus Interface Device. 


D.1.1 VXIbus Instrument Protocols 

RULE D.1.1: 

A VXIbus instrument SHALL be a Message Based Device and provide the VXIbus word serial 
communication protocol. 

VXIbus instruments communicate with the core set of commands and events described in the following 
sections. 

OBSERVATION D.1.1: 

The following commands are considered to be Instrument Protocol commands: 

• Byte Available 

• Byte Request 

• Clear 

• Trigger 

• Set Lock 

• Clear Lock 

• Read STB 

The Byte Transfer Protocol is used to communicate with VXIbus instruments. Other protocols may also be 
used. 

RULE D.l .2: 

VXIbus Instruments SHALL support the Byte Transfer Protocol. 

PERMISSION D.1.1: 

VXIbus Instruments MAY support other Word Serial data transfer protocols. 

RULE D.l.3: 

A VXIbus instrument SHALL NOT have more than one Word Serial data transfer protocol active at a time. 

RULE D.l .4: 

When a VXIbus Instrument enters the Normal Operation State, it SHALL become enabled for the Byte 
Transfer Protocol. 
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D.1.1.1 DATA TRANSFER from COMMANDERS to INSTRUMENTS 

The Byte Available command is used to send a data byte (DAB) to a VXIbus instrument. The command 
includes an END bit which may be used as a message terminator. 

RULE D.1.5: 

All VXIbus instruments SHALL support the Byte Available command in conformance to the Byte Transfer 
Protocol. 

OBSERVATION D.1.2: 

The Byte Transfer Protocol provides for an instrument to hold off incoming Byte Available commands while 
still allowing other commands such as Clear and Read STB. 

OBSERVATION D.1.3: 

The state of DIR when the Write Ready bit becomes asserted allows a Commander to determine whether or not 
to send a Byte Available or Trigger command to the Servant. If DIR is set, then the Commander may send a 
Byte Available or Trigger command. 


D.1.1.2 DATA TRANSFER from INSTRUMENTS to COMMANDERS 

Data transfer from an instrument to its Commander is initiated by the Commander by sending a Byte Request 
command to the VXIbus instrument. The instrument responds by making the data byte available in its data 
registers. The returned data includes an END bit which may be used as a message terminator. 

RULE C.1.6: 

All VXIbus instruments SHALL support the Byte Request command in conformance to the Byte Transfer 
Protocol. 

OBSERVATION D.1.4: 

The Byte Transfer Protocol provides for an instrument to indicate the presence of data in its output buffer (thus 
readiness for a Byte Request command). 

OBSERVATION D.1.5: 

The state of DOR when the Write Ready bit becomes asserted allows a Commander to determine whether or 
not to send a Byte Request command to the Servant. If DOR is set, then the Commander can send the Byte 
Request command. 


D.I.I.3 CUEARING a VXIbus INSTRUMENT 

A VXIbus instrument which receives a Clear command will respond according to the following rules (in 
addition to Rules C.2.100 and C.2.101). 

RULE D.1.7: 

Upon receipt of the Clear command the VXIbus instrument SHALL perform the following actions: 

• clear its input buffer (set DIR) 

• clear its output queue (clear DOR, if appropriate) 

• become ready to process new commands 

Eurther clarification of the proper operation of the Clear command may be found in the IEEE 488.2 
Standard Section 5.8, "Device Clear Requirements". 
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OBSERVATION D.1.6: 

The VXIbus Clear command may affect current instrument operation for VXIbus instruments, while for 
VXIbus IEEE 488.2 instruments it will not. 

RULE D.1.8: 

All VXIbus instruments SHALL support the Clear command. 

RULE D.1.9: 

In response to a Clear command, a VXIbus instrument that supports multiple Word Serial data transfer 
protocols SHALL NOT disable the currently active data transfer protocol or enable another data transfer 
protocol. 


D.1.1.4 TRIGGERING an INSTRUMENT 

RULE D.1.10: 

All VXIbus instruments which support a trigger function SHALL be capable of being triggered via the Trigger 
command. 

PERMISSION D.1.2: 

VXIbus Instruments may support other methods of triggering (i.e. P2 or P3 hardware trigger busses). 

RULE D.1.11: 

When a VXIbus instrument is not ready to process a Trigger command it SHALL clear to zero (0) the DIR bit 
in its Response register. 

OBSERVATION D.1.7: 

When a VXIbus instrument is ready to process a Trigger command it will normally set to one (1) the DIR bit in 
its Response register. 


D.I.I.5 LOCAL LOCKOUT 

A Commander can issue the Set Lock command to its Servant if it wishes the Servant to ignore commands 
from local sources. The Clear Lock command is used by a Commander to cause a device to exit the Lock 
state. 

RULE D.1.12: 

IF an instrument supports the Set Lock command, 

THEN upon receipt of the Set lock command it SHALL clear (to zero (0)) the Locked* bit (bit 7) in its 
Response register. 

RULE D.1.13: 

IF an instrument supports the Clear Lock command, 

THEN upon receipt of the Clear lock command it SHALL set (to one (1)) the Locked* bit (bit 7) in its 
Response register. 

RULE D.1.14 

IF an instrument supports the Set Lock command, 

THEN local control of the device SHALL be disabled upon the receipt of a Set Lock command. 

RULE D.1.14 

IF an instrument has had local control disabled by the receipt of a Set Lock command, 

THEN local control of that device SHALL NOT be re-enabled until the receipt of a Clear Lock command. 
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PERMISSION D.1.3: 

Local operations which do not affect device operations will be allowed while the device is in the locked state 
as per IEEE 488.2. 

PERMISSION D.1.4: 

VXIbus instruments MAY implement the Set Lock and Clear Lock commands. 

RECOMMENDATION D.1.1: 

If an instrument implements either the Set Lock or the Clear Lock command then it should implement both 
commands. 


D.1.1.6 SRQ OPERATION 

When a device needs to request service on an interface, it sends a request true event to its Commander. This 
event can be sent via the event form of the interrupt response word or as a signal. If the need for service is 
removed, a device which has previously sent a request true event must send the request false event. This event 
is sent in an analogous manner to the request true event. 

PERMISSION D.1.5: 

VXIbus instruments MAY implement the request true and request false events. 

RULE D.1.16: 

IF a VXIbus Instrument has VMEbus Master capability, 

THEN the request true and request false events SHALL be sent using signals (unless modified by the 
Asynchronous Mode Control command). 

RULE D.1.17: 

IF a VXIbus Instrument does not have VMEbus Master capability, 

THEN the request true and request false events SHALL be sent using interrupts (unless modified by the 
Asynchronous Mode Control command). 


D.1.1.7 SPOLL OPERATION 
PERMISSION D.1.6: 

VXIbus instruments MAY implement the Read STB command. 

RULE D.1.18: 

A VXIbus instrument which implements the Read STB command SHALL send as bit 6 of its response a bit 
that is equivalent to the MSS bit of the *STB? response in IEEE Standard 488.2-1987. 

OBSERVATION D.1.8: 

This bit is to indicate whether or not the device is currently requesting service. In an interface other than IEEE 
488.1 the RQS function may not be available. In this case, the device indicates its current needs to the 
requester via this bit. 


D.1.1.8 ERROR REPORTING 

Error reporting is divided into two parts: Word Serial Protocol errors and errors resulting from messages sent 
via the Byte Available command. Word Serial Protocol error reporting is described in Section C.3.3.4, "Error 
Handling". Errors which are the result of higher-level messages received via the Byte Available command are 
reported via the request true event. 
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RULE D.1.19: 

IF a device reports errors via signals or interrupts as a result of messages received via the Byte Available 
command, 

THEN that device SHALL use the request true event to notify its Commander of the error. 

RECOMMENDATION D.1.2: 

A VXIhus Instrument should follow the IEEE 488.2 error reporting conventions (Reference: IEEE 488.2, 
Sections 11.3 and 11.5) including the enabling and disabling of the request true event generation. 


D.1.1.9 INITIALIZATION 

VXIbus instruments require no initialization beyond that required for all Message Based Instruments. Once a 
VXIbus system is configured, the instruments are ready to process Instrument Protocol commands. 

RULE D.1.20: 

After the receipt of the Begin Normal Operation command, a VXIbus Instrument SHALL become ready to 
accept Instrument protocol commands. 

OBSERVATION D.1.9: 

Normally when a device is ready to accept Instrument protocol commands it will have the following 
indications: DIR=\, DOR=0, Locked=l, Read Ready=0, Write Ready=l and Err*=\. 

OBSERVATION D.1.10: 

A device which implements a self initiated trigger, may have data ready for output when it is ready to accept 
Instrument protocol commands. It will indicate this with DOR=l. 


D.1.2 VXIbus IEEE-488.2 Instrument Protocols 

This section describes additions to the VXIbus Instrument Protocols which apply to VXIbus IEEE-488.2 
Instruments. 

RULE D.1.21: 

All VXIbus IEEE-488.2 Instruments SHALL comply with all the rales for VXIbus Instruments. 


D.1.2.1 CLEARING a VXIbus IEEE-488.2 INSTRUMENT 
RULE D.1.22: 

The Clear command SHALL NOT affect current instrument operation for a VXIbus IEEE-488.2 Instrument. 

RULE D.1.23: 

VXIbus IEEE-488.2 Instruments SHALL implement the Clear command according to the specifications in the 
IEEE 488.2 Standard, Section 5.8, "Device Clear Requirements". 


D.1.2.2 TRIGGERING an IEEE-488.2 INSTRUMENT 
OBSERVATION D.1.11: 

VXIbus IEEE 488.2 instruments MAY support either DTO or DTI IEEE 488.1 subsets. 
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D.1.2.3 LOCAL LOCKOUT 
OBSERVATION D.1.12: 

VXIbus IEEE 488.2 instraments MAY support either RLO or RLI IEEE 488.1 subsets. 


D.1.2.4 SSRQ OPERATION 
RULE D.1.24: 

All VXIbus IEEE 488.2 instruments SHALL implement the request true and request false events. 


D.1.2.5 SPOLL OPERATION 
RULE D.1.25: 

All VXIbus IEEE 488.2 instruments SHALL implement all the required 488.2 status reporting registers and 
protocols and the Read STB command. 

OBSERVATION D.1.13: 

The response to a Read STB command will have a bit 6 which is equivalent to the MSS bit of the STB? 
response in IEEE Standard 488.2-1987. 
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D.2 488-VXIbus INTERFACE 

The 488-VXIbus interface device converts IEEE 488 protocols to VXIbus instrument control protocols, 
allowing IEEE 488 external controllers to control VXIbus instruments in a manner analogous to a typical rack 
and stack instrument system. The primary function of the 488-VXIbus Interface device is to route the IEEE 
488 messages to the appropriate VXIbus instrument and to return the results from the instrument to the external 
IEEE 488 controller. A VXIbus system may or may not provide one or more 488-VXIbus Interface devices. 

RULE D.2.1: 

A 488-VXIbus Interface SHALL be a Message Based Commander. 

RULE D.2.2: 

A 488-VXIbus Interface device SHALL support the receipt of signals. 

RULE D.2.3: 

A 488-VXIbus Interface device SHALL be an Interrupt Handler. 

PERMISSION D.2.1: 

When a 488-VXIbus Interface device detects that a Servant has not recognized a command (error response 
from the Servant), the interface action is left to the device designer. 


D.2.1 IEEE 488 Address Mapping 

The mapping of an IEEE 488 address to VXIbus Logical Address is a function which is handled by the 
488-VXIbus Interface device. The particulars of this mapping are interface device specific. Several potential 
mappings are described below: 

• The 488-VXIbus Interface device supports primary addressing of 31 potential addresses. The 31 IEEE 
488 addresses will be associated one for one with 31 Logical Addresses of the VXIbus instruments. 

• The 488-VXIbus Interface device supports secondary addressing of 31 potential secondary addresses. The 
488-VXIbus Interface device will provide a means of selecting the primary address. The 31 IEEE 488 
secondary addresses will be associated one for one with 31 Logical Addresses of the VXIbus instruments. 

• The 488-VXIbus Interface device supports a single primary IEEE 488 address through which all VXIbus 
Instruments are addressed. The particular language constructs which implement routing are up to the 
interface device designer. 

OBSERVATION D.2.1: 

488-VXIbus Interface devices can use these or any other address mapping scheme. 

OBSERVATION D.2.2: 

488-VXIbus Interface devices which implement different address mapping schemes might require address 
changes for portability. The application which controls VXIbus instruments must consider the address 
mapping. 
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D.2.2 488-VXIbus Interface Device to IEEE 488 Bus Eunctions 

A 488-VXIbus interface device will provide a set of capabilities which enables a VXIbus instrument to comply 
with IEEE 488.2. The actual choice of whether or not a VXIbus instrument will implement IEEE 488.2 is left 
to the instrument designer. 

RULE D.2.4: 

488-VXIbus Interface device SHALL implement the following IEEE 488.1 subsets, in an IEEE 488.2 
compatible fashion, for each VXIbus Instrument it controls: 

SHI Source Handshake. 

AHl Acceptor Handshake. 

T6 Addressing Talker or TE6 Extended Addressing Talker - (No Talk Only Mode). 

L4 Listener or LE4 Extended Listener - (No Listen Only Mode). 

SRI Service Request. 

DCl Device Clear. 

DTI Device Trigger. 

OBSERVATION D.2.3: 

The preceding rale guarantees that a VXIbus Instrument which is compatible with IEEE 488.2 will be IEEE 
488.2 compatible when accessed through the 488-VXIbus interface device. 

PERMISSION D.2.2: 

RLI Remote/Local capability MAY be implemented by the 488-VXIbus Interface device. 

PERMISSION D.2.3: 

Controller capability MAY be implemented by the 488-VXIbus Interface device. 

RULE D.2.5: 

IF a 488-VXIbus Interface device supports controller capability, 

THEN the controller SHALL follow the IEEE 488.2 implementation. 

RECOMMENDATION D.2.1: 

488-VXIbus Interface devices should implement E2 three-state electrical drivers. 

RULE D.2.6: 

IF a 488-VXIbus Interface device implements parallel poll capability 
THEN it SHALL be implemented according to IEEE 488.2 rales (PPl). 

RULE D.2.7: 

The 488-VXIbus Interface device SHALL preserve the order of received messages, including data bytes 
(DAB), END messages. Group Execute Trigger, Device Clear and Selective Device Clear. 

D.2.3 VXIbus Instrument Protocol 

RULE D.2.8: 

VXIbus Instruments and VXIbus Interface devices SHALL be logically partitioned according to Eigure D.l. 
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VXIbus 

Instrument 

Required 

Commands 


VXIbus Interface 
Device 


request true 
request false 


VXIbus Instrument 
Device 


Byte Request 
Byte Available 
Clear 


Trigger 
Read STB 
Set Lock 
Clear Lock 


VXIbus 

Instrument 

Optional 

Commands 


VXIbus 

Instrument 

Optional 

Signals 


Figure D.l. VXIbus Instrument Protocol 


RULE D.2.9: 

IEEE 488.2 compatible VXIbus Instruments SHALL be logically partitioned according to Eigure D.2. 


D.2.3.1 DATA TRANSFER from INTERFACE DEVICE to VXIbus INSTRUMENT 
RULE D.2.10: 

IF EOT is asserted on receipt of a data byte from the external interface, 

THEN the interface device SHALL send the Byte Available command with END asserted to all Servants 
which are addressed to listen (LACS). 

ELSE the interface device SHALL send the Byte Available command with END unasserted to all Servants 
which are addressed to listen (LACS). 

OBSERVATION D.2.4: 

A VXIbus Interface device cannot send END for message terminators that do not have EOI asserted. 

OBSERVATION D.2.5: 

A VXIbus Interface device cannot send a Byte Available command to an instrument which has its DIR bit 
cleared to zero (0). 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 





Section D: VXIbus DEVICE IMPLEMENTATIONS 


Page 205 



IEEE 448.2 Compatible VXIbus Instrument 


Figure D.2. Message Exchange Control Interface Eunctional Blocks 
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D.2.3.2 DATA TRANSFER from VXIbus INSTRUMENT to VXIbus INTERFACE 

DEVICE 

RULE D.2.11: 

When an interface device receives a byte request from the external interface it SHALL perform the following 

actions on the VXIbus: 

The interface device sends the Byte Request command to the Servant device which is currently addressed to 
talk (TAGS). 

The interface device then reads the result of the Byte Request command from the appropriate Servant device 
using the word serial protocol. 

The interface places the DAB portion of the response on external interface. Simultaneously, the interface 
SHALL assert the EOI line if the END bit in the response is asserted; else the interface SHALL NOT assert 
EOT 

OBSERVATION D.2.6: 

A VXIbus Interface device cannot send a Byte Request command to an instrument which has its DOR bit 

cleared to zero (0). 


D.2.3.3 DEVICE CLEAR OPERATION 

This section describes the operation of a 488-VXIbus Interface device when it receives an IEEE 488 device 
clear message. 

RULE D.2.12: 

The 488-VXIbus Interface device SHALL send the Clear command to all VXIbus instruments which it 
controls when the 488-VXIbus interface device receives the 488.1 DCL command. 

RULE D.2.13: 

The 488-VXIbus Interface device SHALL send the Clear command to all VXIbus instruments which are 
addressed to listen and which it controls when the 488-VXIbus interface device receives the 488.1 SDC 
command. 

RULE D.2.14: 

The 488-VXIbus Interface device SHALL hold off NDAC on the IEEE 488 interface until the Clear command 
has been sent to all affected devices. 

RULE D.2.15: 

The 488-VXIbus interface SHALL NOT perform a soft reset of any VXIbus instruments in response to any 
488.1 defined commands or messages, such as DCL, SDC or lEC. 


D.2.3.4 TRIGGER OPERATION 

This section describes the operation of a 488-VXIbus Interface device when it receives an IEEE 488 trigger 
message. 

RULE D.2.16: 

Upon receipt of the 488.1 GET message, the 488-VXIbus Interface device SHALL send the Trigger command 
to all VXIbus instruments which 

are addressed to listen, 

and are controlled by that particular interface device, 
and implement the Trigger command. 
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and are not configured for triggering via an alternate trigger implementation. 

OBSERVATION D.2.7: 

The above rale allows an interface which knows that some Servants provide alternate trigger implementations 
to be triggered via that implementation. 

RULE D.2.17: 

The 488-VXIbus Interface device SHALL hold off NDAC on the IEEE 488 interface until the Trigger 
command has been sent to all affected devices. 

OBSERVATION D.2.8: 

There will be a time delay between the receipt of the Trigger command by the various VXIbus instruments in 
the VXIbus system. 

OBSERVATION D.2.9: 

The possible inclusion of PI only VXIbus devices in the system mandates a Trigger command rather than use 
of a trigger line. 

RULE D.2.18: 

A VXIbus Interface device SHALL NOT send a Trigger command to an instrument which has its DIR bit 
cleared to zero (0). 

D.2.3.5 IEEE 488 REMOTE LOCAL 

This section discusses the implementation of the IEEE-488 RLI functions within the context of a VXIbus 
system. Local is defined as operations which are initiated from any non-VXIbus device interface. 


D.2.3.5.1 Locking Devices 

The 488-VXIbus Interface will issue the Set Lock and Clear Lock commands according the remote/local state 
of the associated device as maintained by the state table according to the rales below. 

RULE D.2.19: 

IF A 488-VXIbus Interface Device implements RLI, 

THEN it SHALL issue the Set Lock command to a device which implements the Set Lock command when the 
interface detects that device should have entered the RWLS state of the IEEE-488.1. 

RULE D.2.20: 

IF A 488-VXIbus Interface Device implements RLI, 

THEN it SHALL issue the Clear Lock command to a device which implements the Clear Lock command 
when the interface detects that device should have exited the RWLS state of the IEEE-488.1. 


D.2.3.6 SRQ OPERATION 

This section describes the 488-VXIbus Interface device requirements for support of the IEEE 488.2 SRQ 
capability. 488.2 simplifies the implementation of service request by requiring two synchronization messages 
which control the assertion of the 488.1 rsv message. Two messages are sourced by the device: the reqt is used 
to assert a 488.1 rsv (requires service message) and the reqf is used to asynchronously remove rsv. In a 
VXIbus system these messages are sent using the request true and request false events. The 488.2 
synchronization protocols allow the interface device to: 

Assert SRQ if a previously "enabled" condition occurs. 
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Keep SRQ asserted until the controller has recognized the service request and serial polled the device or the 
instrument has removed the request (by sending a request false event). 

Release SRQ when serial polled so that the controller can detect a SRQ from another instrument. 

Assert SRQ again if another condition occurs whether or not the controller has cleared the first condition. 

Eor further clarification of SRQ and serial poll operation of the 488-VXIbus Interface device, see IEEE 488.2, 
Section 11.3.3, "Service Request Generation". 

RULE D.2.21: 

A 488-VXIbus Interface device, upon receipt of a request true event from a VXIbus instrument, SHALL set 
the 488.1 rsv message true. 

RULE D.2.22: 

A 488-VXIbus Interface device, upon receipt of a request false event from a VXIbus instrument, SHALL set 
the 488.1 rsv message false only if no request true has been received from any other VXIbus Instrument. 

OBSERVATION D.2.10: 

The VXIbus interface device has to keep track of requests for each of its Servants in order to properly control 
the SRQ line on the IEEE 488.1 interface. 

RULE D.2.23: 

A 488-VXIbus Interface device SHALL implement the IEEE 488.2 SRQ protocols. 

OBSERVATION D.2.11: 

Request true and request false events may be sent via either interrupts or signals. The 488-VXIbus Interface 
device is required to accept these events regardless of method of transmission. 


D.2.3.7 SPOLL Operation 

This section discusses the implementation of the IEEE 488 Serial Poll function within the context of a VXIbus 
system. The IEEE 488 specific functions, such as whether the device is in SPAS, are managed by the IEEE 
488 VXIbus Interface device. When the IEEE 488-VXIbus interface device is ready to source the serial poll 
response to the 488 interface, it sends a Read STB command to the device for which the serial poll was 
requested. It then reads (using the word serial protocol) the status byte of the polled instrument and makes this 
byte available to the interface as the serial poll response. 

RULE D.2.24: 

IF a VXIbus instrument supports the Read STB command, 

THEN the IEEE 488-VXIbus Interface device SHALL respond to a serial poll of that instrument with the 
status byte obtained by the Read STB command. 

RULE D.2.25: 

IF a VXIbus instrument doesn't support the Read STB command 

THEN the IEEE 488-VXIbus Interface device SHALL respond to a serial poll of that instrument with bit 6 of 
the serial poll response byte properly indicating the rsv state of the instrument. Bit 6 will be set (to one (1)) if 
the instrument is requesting service, otherwise it is cleared (to zero (0)). 

RULE D.2.26: 

A IEEE 488-VXIbus Interface device SHALL implement SPOLL in the manner specified by IEEE 488.2. 
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E. COMMAND and EVENT FORMATS 

This section summarizes the required and optional commands and events which support the instrument 
protocols. 


E.l WORD SERIAL COMMANDS 

The following commands are the standard set of VXIbus device commands which are sent with the word serial 
protocol. 

RULE E.1.1 

Message Based Devices SHALL implement the appropriate subsets of the following command set as specified 
in Table E.l and E.2. 



Primary Classification 

CDMR 

MASTER 

SlotO 

Comments 

All MBD 

I 

14 

Abort Normal Operation 

R 

R 

R 

R 

R 

R 


Begin Normal Operation 

R 

R 

R 

R 

R 

R 


Byte Available 


R 

R 




Requires DIR bit 

Byte Request 


R 

R 




Requires DOR bit 

Clear 

R 

R 

R 

R 

R 

R 


Clear Lock 







Required with RE 1 
Requires Locked* bit 

End Normal Operation 

R 

R 

R 

R 

R 

R 


Grant Device 




R 




Identify Commander 




R 

R 



Read MODID 






R 


Read Protocol 

R 

R 

R 

R 

R 

R 


Read Protocol Error 

R 

R 

R 

R 

R 

R 


Read STB 



R 





Read Servant Area 




R 




Release Device 




R 




Set Lock 







Required with RE 1 
Requires Locked* bit 

Set Lower MODID 






R 


Set Upper MODID 






R 


Trigger 







Optional for all devices 
Requires DIR bit 


R — Required for this type of device. 

TABLE E.l. General Command Requirements 
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Programmable 

Handler 

Programmable 

Interrupter 

Response 

Generation 

Event 

Generation 

Comments 

Assign Handler Line 

R 





Assign Interrupter Line 


R 




Asynchronous Mode Control 



R 

R 


Control Event 




R 


Control Response 



R 



Read Handler Line 

R 





Read Handlers 

R 





Read Interrupter Line 


R 




Read Interrupters 


R 





R — Required for this type of device 


TABLE E.2. Asynchronous Command Requirements 
The following is a list of commands: 


Abort Normal Operation: The Abort Normal Operation command is used to cause a device to cease 
normal operation. Upon receipt of this command the device returns to its default configuration, 
aborting all operations. The aborted state is defined as follows: All VMEbus Master activity is halted. 
Pending interrupts are unasserted. No new bus requests or interrupts may be asserted. The device is in 
a generally inactive state and is ready to accept commands. 

The syntax of the Abort Normal Operation command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

I 

1 

0 

0 

1 

0 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

eration has completed (the device is 
; following format: 

in the aborted state), response data is 







Bit# 









15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


placed in the Data 
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Assign Handler Line: The Assign Handler Line command is used to assign a VMEbus IRQ line to a particular 
Interrupt Handler in the Servant device. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 

4 

3 

2 1 0 

1 

0 

1 

0 

1 

0 

0 

1 

X 

Hand 

_ID 

X 

Line 


• X: Don't care. The value written to this bit has no effect. 

• Hand_ID: This is a unique identifier of the particular Interrupt Handler being assigned. It has a range of I 
to 7. Within a device, multiple handlers are identified in consecutive order, starting at 1. 

• Line: This is the VMEbus IRQ line number. A value of zero (Oie) indicates that the handler is to be 
disconnected. 

When the assignment operation has completed, response data is placed in the Data Low register in the following 
format: 


Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


• Status: This field indicates the execution status of the command. It may have the following values: 

Ejg: The command successfully completed. 

7 16 : Command failed - The handler referenced in the Hand_ID field is unknown to this device. 

OBSERVATION E.1.1 

There is no implicit relationship between the Handler ID (Hand_ID) and the functionality of the associated 
handler. 
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Assign Interrupter Line: The Assign Interrupter Line command is used to assign a VMEbus IRQ line to a 
particular Interrupter in the Servant device. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

II 

10 

9 

8 

7 

6 5 4 

3 

2 I 0 

I 

0 

I 

0 

I 

0 

I 

0 

X 

Int_ID 

X 

Line 


• X: Don't care. The value written to this bit has no effect. 

• Int_ID: This is a unique identifier of the particular Interrupter being assigned. It has a range of I to 7. 
Within a device, multiple Interrupters are identified in consecutive order, starting at I. 

• Line: This is the VMEbus IRQ line number. A value of zero (Ois) indicates that the Interrupter is to be 
disconnected. 

When the assignment operation has completed, response data is placed in the Data Low register in the following 
format: 


Bit# 


15 14 13 

12 

II 

10 

9 

8 

7 

6 

5 

4 

3 

2 

I 

0 

Status 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

0 


• Status: This field indicates the execution status of the command. It may have the following values: 

Eig: The command successfully completed. 

7ig: Command failed - The handler referenced in the Int_ID field is unknown to this device. 

OBSERVATION E.1.2: 

There is no implicit relationship between the Interrupter ID (Int_ID) and the functionality of the associated 
Interrupter. 
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Asynchronous Mode Control: The Asynchronous Mode Control command is used by a Commander to direct 
the path of events and responses. The syntax of this command is defined in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 

3 

2 

1 

0 

1 

0 

1 

0 

1 

0 

0 

0 

X 

Resp. En* 

Event En* 

Resp. Mode 

Event Mode 


The bits have the following meanings: 

• X: Don't care. The value written to this bit has no effect. 

• Resp. En*: A zero (0) enables generation of responses. A one (1) disables generation of responses. 

• Event En*: A zero (0) enables generation of events. A one (1) disables generation of events. 

• Resp. Mode: A one (1) indicates that responses should be sent as signals. A zero (0) indicates that 

responses should be sent as interrupts. This bit is meaningful only if the Resp En* bit is zero (0). 

• Event Mode: A one (1) indicates that events should be sent as signals. A zero (0) indicates that events 
should be sent as interrupts. This bit is meaningful only if the Event En* bit is zero (0). 

The result data is placed in the Data Low register with the following format. This result is a confirmation/denial 
of the command. 


Bit# 


15 14 13 12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

Resp. En* 

Event En* 

Resp. Mode 

Event Mode 


The bits have the following meanings: 

• Status: This field indicates the execution status of the command. It may have the following values: 

Ejg: The command successfully completed as expected. 

7 16 : Command failed - A requested option is not supported. 

• Resp. En*: A zero (0) indicates that the generation of responses is enabled, 
generation of responses is disabled. 

• Event En*: A zero (0) indicates that the generation of events is enabled, 
generation of events is disabled. 

• Resp. Mode: A one (1) indicates that responses are being sent as signals. A zero (0) indicates that 
responses are being sent as interrupts. This bit is meaningful only if the Resp En* bit is zero (0). 

• Event Mode: A one (1) indicates that events are being sent as signals. A zero (0) indicates that events are 
being sent as interrupts. This bit is meaningful only if the Event En* bit is zero (0). 


A one (1) indicates that the 
A one (1) indicates that the 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 




Section E: Command and Event Eormats 


Page 215 


Begin Normal Operation: The Begin Normal Operation command notifies the device that it can begin normal 
operation now. A Commander may not initiate any VMEbus operations after power-up until it receives the 
Begin Normal Operation command. It then sends the Begin Normal Operation command to all of its current 
Message Based Servants and begins normal execution of commands and/or application programs. The 
Top_Level field of fhe Begin Normal Operation command is provided fo inform a device whefher or nof if is a 
fop level Commander. The synfax of fhis command is defined in fhe following fable. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

0 

Top Level 

1 

1 

1 

1 

1 

1 

1 

1 


• Top Level: A one (1) in this field indicates that the device is a top level Commander. A zero (0) indicates 
that that it is a Servant to another device. 

When the begin operation has completed, response data is placed in the Data Low register in the following 
format: 


Bit# 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Status 


State 


Logical Address 


• Status: This field indicates the execution status of the command. It may have the following values: 

Lig: The Begin Normal Operation command has been successfully executed. The value LEie is 
reported in the Logical Address field. 

7i 6: The Commander device is not able to command a Servant. The Servant's Logical Address is 
reported in the Logical Address field. 

6i 6: The Commander device is not able to configure a Servant device. The Servants Logical Address is 
reported in the Logical Address field. 

5 16 : The Commander device timed out when waiting for response from a Servant device. The Servant's 
Logical Address is reported in the Logical Address field. 

4i 6: The device is not able to successfully initialize itself. The value LEie is reported in the Logical 
Address field. 

3i 6: The device is not able to be a top level Commander. The value LEie is reported in the Logical 
Address field. 

2i 6: The device must be a top level Commander. The value LEie is reported in the Logical Address 
field. 

1 16 : An undefined error was caused. The value LEi6 is reported in the Logical Address field. 

• State: This field indicates the state of this device and its sub-tree. It may have the following values: 

3 16 : This device and all of its Servant tree are in the CONLIGURE sub-state. 

7i 6: This device is in the CONLIGURE sub-state, however at least one device in its Servant tree is in 
the NORMAL OPERATION sub-state. 

Bie: This device is in the NORMAL OPERATION sub-state, however at least one device in its Servant 
tree is in the CONLIGURE sub-state. 
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Eig: This device and all of its Servant tree are in the NORMAL OPERATION sub-state. 

• Logical Address: This field contains the Logical Address corresponding to the status field values. 


Byte Available: The Byte Available command is used by a Commander fo send a byte of dafa fo a Servanf 
device. The END field idenlifies fhaf Ibis is fhe lasf byte of fhe message. The synfax of fhis command is 
defined in fhe following fable. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 4 3 2 

1 

0 

1 

0 

1 

1 

1 

1 

0 

END 

Datum 


Byte Request: The Byte Request command is used by a Commander to read a byte of data from a Servant 
device. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

1 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 


The result data is placed in the Data Low register with the following format. The END field is used to indicate 
the last byte of the message. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 4 3 2 

1 0 

1 

1 

1 

1 

1 

1 

1 

END 

Datum 


Clear: The Clear command is used by a Commander to cause a Servant device to clear the VXIbus interface 
and any pending operations. Any initiated operations in the receiving device are undisturbed. The syntax of 
this command is defined in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


Clear Lock: The Clear Lock command is used by a Commander to cause a Servant device to exit the locked 
state. When a device receives this command it will set its Locked* bit. The syntax of this command is defined 
in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 
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Control Event: The Control Event command is used by a Commander to selectively enable the generation of 
events by a Servant. A one (1) in the enable field enables the generation of the specific event. A zero (0) in the 
enable field disables the generation of the specific evenf. The synfax of fhis command is defined in fhe 
following fable. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 

4 3 2 

1 0 

1 

0 

1 

0 

1 

1 

1 

1 

Enable 

Event 


• Event: These bits (6 <— 0) are the identifying bits (14 <— 8) of the event being enabled/disabled. See 
Section E.4, "Protocol Events", for further information. 

The device returns the following data in the Data Low register: 

Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


• Status: This field indicates the execution status of the command. It may have the following values: 
Eig: The command successfully completed. 

7ig: Command failed - The event referenced is not generated by this device. 
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Control Response: The Control Response command is required for devices which implement response signals 
or response interrupts. It is used to enable response signals or response interrupts on certain response register 
bit transitions. The syntax of this command is defined in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

0 

0 

0 

1 

1 

1 

1 

X 

B14* 

DOR* 

DIR* 

Err* 

RR* 

WR* 

EHS* 


The bits have the following meanings: 

• X: Don't care. The value written to this bit has no effect. 

• B14*: A zero (0) enables a signal/interrupt on transitions of bit 14 of the Response register. A one (1) 
disables this capability. Since bit 14 of the Response register is reserved (always one), the value of this bit 
may be ignored by the Servant. 

• DOR*: A zero (0) enables a signal/intermpt on a 0—>1 transition of the DOR bit. A one (1) disables this 
capability. 

• DIR*: A zero (0) enables a signal/interrupt on a 0—>1 transition of the DIR bit. A one (1) disables this 
capability. 

• Err*: A zero (0) enables a signal/interrupt on a 1—>0 transition of the Err* bit. A one (1) disables this 
capability. 

• RR*: A zero (0) enables a signal/interrupt on a 0—>1 transition of the Read Ready bit. 
this capability. 

• WR*: A zero (0) enables a signal/intermpt on a 0—>1 transition of the Write Ready bit. 
this capability. 

• EHS*: A zero (0) enables a signal/intermpt on a 1—>0 transition of the FHS Active* hit. 
this capability. 

The result data is placed in the Data Low register with the following format. This result is a confirmation/denial 

of the command. 


A one (1) disables 
A one (1) disables 
A one (1) disables 


Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

B14* 

DOR* 

DIR* 

Err* 

RR* 

WR* 

EHS* 


The bits have the following meanings: 

• Status: This field indicates the execution status of the command. It may have the following values: 

Eig: The command successfully completed as expected. 

7ig: Command failed - an unsupported bit transition was requested. 

• B14*: A zero (0) indicates that intermpt/signal generation on transitions of bit 14 of the Response register is 
enabled. A one (1) indicates that this capability is disabled. Since bit 14 of the Response register is 
reserved and should never change, this bit should always be set to one (1). 

• DOR*: A zero (0) indicates that intermpt/signal generation on 0—>1 transitions of the DOR bit is enabled. 
A one (1) indicates that this capability is disabled. 
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• DIR*: A zero (0) indicates that interrapt/signal generation on 0—>1 transitions of the DIR bit is enabled. A 
one (1) indicates that this capability is disabled. 

• Err*: A zero (0) indicates that intermpt/signal generation on 1—>0 transitions of the Err* bit is enabled. A 
one (1) indicates that this capability is disabled. 

• RR*: A zero (0) indicates that intermpt/signal generation on 0—>1 transitions of the Read Ready bit is 
enabled. A one (1) indicates that this capability is disabled. 

• WR*: A zero (0) indicates that interrapt/signal generation on 0—>1 transitions of the Write Ready bit is 
enabled. A one (1) indicates that this capability is disabled. 

• EHS*: A zero (0) indicates that interrapt/signal generation on 1—>0 transitions of the FHS Active* bit is 
enabled. A one (1) indicates that this capability is disabled. 

OBSERVATION E.1.3: 

A Servant may not implement response signals or response interrupts for some of the defined bits. Such a 

Servant will always return a one (1) in the corresponding bit position(s) in its response to the Control Response 

command. 
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End Normal Operation: The End Normal Operation command is used to cause a Commander to cease normal 
operation in an orderly manner. Upon receipt of this command the Commander issues the End Normal 
Operation command to all of its Message Based Servants. The Commander is responsible for halting all its 
Servants. The "ended" state is defined as follows: All VMEbus Master activity is halted. Pending interrupts are 
unasserted. No new bus requests or interrupts may be asserted. The device is in a generally inactive state and is 
ready to accept commands. 

The syntax of the End Normal Operation command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 


When the "ending" operation has completed, response data is placed in the Data Low register in the following 
format: 


Bit# 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Status 


State 


Logical Address 


• Status: This field indicates the execution status of the command. It may have the following values: 

Eig: The End Normal Operation command has been successfully executed. The value EEig is 
reported in the Logical Address field. 

Tig: The device was already in the CONEIGURE sub-state. The value EEig is reported in the 
Logical Address field. 

fiig: The Commander device timed out when waiting for the response from a Servant device. The 
Servants Logical Address is reported in the Logical Address field. 

Sig: The device is not able to end its operation in a consistent manner. The value LEig is reported 
in the Logical Address field. 

4i 6: The Commander device is not able to deactivate a Servant. The Servants Logical Address is 
reported in the Logical Address field. 

3i 6: An undefined error was caused. The value LEig is reported in the Logical Address field. 


• State: This field indicates the state of this device and its sub-tree. It may have the following values: 
Lig: This device and all of its Servant tree are in the CONEIGURE sub-state. 


Big: This device is in the CONEIGURE sub-state, however at least one device in its Servant tree is 
in the NORMAL OPERATION sub-state. 


9ig: This device is in the CONEIGURE sub-state, however the sub-states of the devices in its 
Servant tree are unknown. 


Tig: This device is in the NORMAL OPERATION sub-state, however at least one device in its 
Servant tree is in the CONEIGURE sub-state. 


3ig: This device and all of its Servant tree are in the NORMAL OPERATION sub-state. 

• Logical Address: This field contains the Logical Address corresponding to the status field values. 

OBSERVATION E.1.4: 

The End Normal Operation command, unlike the Abort Normal Operation command, allows for the completion 
of some pending operations before "ending". 
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Grant Device: The Grant Device command is used by the Resource Manager to inform a Commander of the 
Logical Address of its Servants. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

0 

1 

1 

1 

1 

1 

1 

Servant’s Logical Address 


Identify Commander: The Identify Commander command is used by a Commander to tell a Servant the 
Commander's Logical Address. This command allows the Servant to reply with signals rather than interrupts. 
The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

0 

1 

1 

1 

1 

1 

0 

Commander’s Logical Address 


Read Handler Line: The Read Handler Line command is used to determine to which VMEbus IRQ line a 
particular Interrupt Handler in the Servant device is connected. The syntax of this command is defined in the 
following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 4 

3 

2 1 0 

1 

0 

0 

0 

1 

1 

0 

0 

X 

Hand_ID 


• X: Don't care. The value written to this field has no effect. 

• Hand_ID: This is a unique identifier of fhe parficular Inferrupf Handler being queried. If has a range of I to 
7. Wifhin a device, mulfiple Infermpfers are idenfified in consecufive order, sfarfing af I. 

The VMEbus IRQ line number is placed in fhe Dafa Low regisfer wifh fhe following formal. 

Bit# 


15 14 13 12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 1 0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Line 


• Status: This field indicates the execution status of the command. It may have the following values: 

Eig: The command successfully completed. 

Tjg: Command failed - The handler referenced in the Hand_ID field is unknown to this device. 

• Line: This is the VMEbus IRQ line number currently assigned. A value of zero (Oie) indicates that the 
handler is disconnected. 
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Read Handlers: The Read Handlers command is used to determine the number of Interrupt Handlers within a 
Servant device. The syntax of this command is defined in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

I 

1 

0 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

• of Interrupt Handlers 

is placed in the Data Low register with the following format. 








Bit# 








15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Hand_no 


Hand_no: This is the number of Interrupt Handlers within this device. 


Read Interrupter Line: The Read Interrupter Line command is used to determine to which VMEbus IRQ line 
a particular Interrupter in the Servant device is connected. The syntax of this command is defined in the 
following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 5 4 

3 

2 1 0 

1 

0 

0 

0 

1 

1 

0 

1 

X 

Int_ID 


• X: Don't care. The value written to this field has no effect. 

• Int_ID: This is a unique identifier of the particular Interrupter being queried. It has a range of I to 7. 
Within a device, multiple Interrupters are identified in consecutive order, starting at I. 

The VMEbus IRQ line number is placed in the Data Low register with the following format. 

Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 1 0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Line 


• Status: This field indicafes fhe execufion sfafus of fhe command. If may have fhe following values: 

Eie: The command successfully complefed. 

7ig: Command failed - The Inferrupfer referenced in fhe Inf_ID field is unknown fo fhis device. 

• Line: This is fhe VMEbus IRQ line number currenfly assigned. A value of zero (Oig) indicates fhaf fhe 
Interrupter is disconnected. 
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Read Interrupters: The Read Interrupters command is used to determine the number of Interrupters within a 
Servant device. The syntax of this command is defined in the following table 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

0 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

• of Interrupters is placed in 

the Data Low register with the following format. 










Bit# 








15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Int_no 


Int_no: This is the number of Interrupters within this device. 


Read MODID: The Read MODID command is used by a Commander to determine the state of the MODID 
lines controlled by a given Slot 0 device. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

1 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 


The resulting MODID status word is placed in the Data Low register with the following format. 


Bit# 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


11 Output Enable 


MODID 


• Output Enable: A one (1) in this position indicates that the Slot 0 device is driving the MODID lines. 


• MODID: This field contains the state of the thirteen MODID lines. 
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Read Protocol: The Read Protocol command is used by a Commander to find out what protocols in addition to 
the Word Serial protocol that the Servant supports. The syntax of this command is defined in the following 
table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


The protocol support word is placed in the Data Low register with the following format. 

Bit# 


15 

14 13 12 11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

Device Dependent 

RSVD 

RG* 

EG* 

0 

PI* 

PH* 

TRG* 

14* 

I* 

ELW* 

LW* 


• Device Dependent: These bits may be defined by the device's manufacturer. 

• RSVD: This bit is always one (1). 

• RG*: A zero (0) in this position indicates that this device is capable of response generation. 

• EG*: A zero (0) in this position indicates that this device is capable of event generation. 

• PI*: A zero (0) in this position indicates that this device supports the Read Interrupters, Read Interrupter 
Line and Assign Interrupter Line commands. 

• PH*: A zero (0) in this position indicates that this device supports the Read Handlers, Read Handler Line 
and Assign Handler Line commands. 

• TRG*: A zero (0) in this position indicates that this device supports the Word Serial Trigger command. 

• 14*: A zero (0) in this position indicates that this device supports the VXIbus IEEE-488.2 Instrument 
protocol. 

• I*: A zero (0) in this position indicates that this device supports the VXIbus Instrument protocol. 

• ELW*: A zero (0) in this position indicates that this device supports the Extended Longword Serial 
Protocol. 

• LW*: A zero (0) in this position indicates that this device supports the Longword Serial Protocol. 
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Read Protocol Error: The Read Protocol Error command is used by a Commander to tell a Servant device to 
report its current error state as the 16-bit response to this command. The Err* bit is always reset before Write 
Ready is asserted in response to this command. After responding to this command, the servant will reset its 
current error state to "No Error". The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 


The error codes are placed in the Data Low register with the following formats. 
No error: 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


Multiple Queries: The device was requested to overwrite previous unread response data. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

1 


Unsupported Command: This device has received a command that it does not implement. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

0 


DIR Violation: This device has received a command that violates the DIR handshake. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

1 

1 


DOR Violation: This device has received a command that violates the DOR handshake. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

1 

0 


Read Ready Violation: This device has received a command that violates the Read Ready handshake. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

0 

1 


Write Ready Violation: This device has received a command that violates the Write Ready handshake. 
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Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

0 

0 


All other error codes are reserved for future use by VXIbus. 


Read STB: The Read STB command is used by a Commander to read the status word from a Servant device. 
The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


The status byte is placed in the Data Low register with the following format. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

1 

1 

1 

1 

1 

1 

1 

Status Byte 


Read Servant Area: The Read Servant Area command is used by the Resource Manager to read the Servant are 
A-size of Commanders in the system. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

0 

0 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 


The Servant are A-size is placed in the Data Low register with the following format. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

Servant Area Size 
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Release Device: The Release Device command is used to cause a Commander to relinquish control of a 
specified Servant device. After releasing the Servant, the Commander will not attempt any further control of 
that Servant. The syntax of this command is defined in fhe following fable. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

0 

0 

0 

1 

1 

1 

0 

Servant Logical Address 


The command ferminafion sfafus is placed in fhe Dafa Low regisfer wifh fhe following formaf. 

Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


• Status: This field indicates the execution status of the command. It may have the following values: 

Eig: The command successfully completed. 

Tjg: Command failed - The requested device is not in the Servant list. 

Set Lock: The Set Lock command is used by a Commander to cause a Servant device to enter the locked state. 
When a device receives this command it will clear its Locked* bit. The syntax of this command is defined in 
the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

0 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 


Set Lower MODID: The Set Lower MODID command is used by a Commander to change the state of the 
MODID lines controlled by a given Slot 0 device. This command only effects the state of MODIDO through 
MODID6 (the lower 7 lines). The enable field, when set to one (1), causes the Slot 0 device to enable its 
MODID drivers (the function of this field is analogous to the output enable bit in the MODID register of a 
register based Slot 0 device). The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 4 3 2 1 0 

1 

0 

1 

0 

1 

1 

1 

0 

Enable 

MODID6-MODIDO 


Upon the completion of the MODID operation, the device places the following response in the Data Low 
register: 


Bit# 


15 14 13 12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


• Status: This field indicates the execution status of the conunand. It may have the following values: 
Eig: The command successfully completed. 
lie- Command failed - The device is not installed in Slot 0. 
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Set Upper MODID: The Set Upper MODID command is used by a Commander to change the state of the 
MODID lines controlled by a given Slot 0 device. This command only effects the state of MODID7 through 
MODID12 (the upper 6 lines). The enable field, when set to one (1), causes the Slot 0 device to enable its 
MODID drivers (the function of this field is analogous fo fhe oufpuf enable bif in fhe MODID register of a 
register based Slof 0 device). The synfax of fhis command is defined in fhe following fable. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 4 3 2 1 0 

1 

0 

1 

0 

1 

1 

0 

1 

Enable 

X 

MODID2-MODID7 


Upon the completion of the MODID operation, the device places the following response in the Data Low 
register: 

Bit# 


15 14 13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

Status 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 


• Status: This field indicates the execution status of the command. It may have the following values: 
Eig: The command successfully completed. 

7ig: Command failed - The device is not installed in Slot 0. 


Trigger: The Trigger command is used by a Commander to cause a Servant device to trigger any previously 
armed operation. The syntax of this command is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

1 

1 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 


User Defined: The blocks of commands with the following bit patterns are reserved for device specific actions. 


Bit# 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


0 


User Defined Conunand 


OBSERVATION E.1.5: 

Commands should indicate the presence of an error with a response which has bit 15 cleared to zero (0). 


All other commands are reserved for future use by VXIbus. 
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E.2 LONGWORD SERIAL COMMANDS 

The following commands are the standard set of VXIbus device commands which are sent with the longword 
serial protocol. 


User Defined: The blocks of commands with the following bit patterns are reserved for device specific 
actions. 


Bit# 

31 30 29<-0 


1 


0 


User Defined Command 


Bit# 

31 30^0 


0 


User Defined Command 


All other commands are reserved for future use by VXIbus. 
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E.3 EXTENDED LONGWORD SERIAL COMMANDS 

The following commands are the standard set of VXIbus device commands which are sent with the Extended 
Longword Serial protocol. 

User Defined: The blocks of commands with the following bit patterns are reserved for device specific 
actions. 


Bit# 

47 46 45 <- 0 


1 


0 


User Defined Command 


Bit# 

47 46 ^ 0 


0 


User Defined Command 


All other commands are reserved for future use by VXIbus. 
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E.4 PROTOCOL EVENTS 

If a Message Based VXIbus Servant interrupts or signals its Commander, it may pass a response or an event in 
its Status/ID word. If the Status/ID word has hit 15 set to "I" then it is defined as an event. If hit 15 is "0" then 
it is defined as a response. The lower 8 hits are the Logical Address of the device. This section only covers 
events. Eor information on signals see the discussions of interrupts and signals in Section C.2.4, "Message 
Based Devices". 


No Cause Given: This event is sent hy a device which has only one reason to signal its Commander. Usually 
this event will carry the meaning of operation complete. The syntax of this event is defined in the following 
table. 


Bit# 


15 

14 

13 

12 

II 

10 

9 

8 

7 6 5 4 3 2 1 0 

I 

I 

I 

I 

I 

I 

I 

I 

Sender’s Logical Address 


Request True: This event is sent by a device when the device requires service from its Commander. The 
syntax of this event is defined in the following table. 


Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

1 

1 

1 

1 

1 

0 

1 

Sender’s Logical Address 


Request False: This event is sent by a device when the device no longer requires service from its Commander. 
The syntax of this event is defined in the following table. 

Bit# 


15 

14 

13 

12 

11 

10 

9 

8 

7 6 5 4 3 2 1 0 

1 

1 

1 

1 

1 

1 

0 

0 

Sender’s Logical Address 


User Defined: This block of events are reserved for use as user defined. The syntax of this event is defined in 
the following table. 


Bit# 


15 

14 

13 12 11 10 9 8 

7 6 5 4 3 2 1 0 

1 

0 

User Defined 

Sender’s Logical Address 


All other events are reserved for future use by VXIbus. 


May 27, 2010 Printing 


VXIbus Specification 


REVISION: 4.0 





Page 232 


Section F: DYNAMIC CONFIGURATION 


R DYNAMIC CONFIGURATION 


Dynamic Configuration is an optional, alternative method of assigning Logical Address to VXIbus devices, 
based upon slot positions. It allows for each slot to contain one or more devices. Provision is made for the 
different devices occupying a slot to share address decoding hardware. In addition. Dynamic Configuration 
requires hardware support in the devices being configured, as well as software support in the Resource 
Manager. 

The following sections present an overview of dynamic configuration, including definition of terms, hardware 
and software requirements and a description of the system configuration algorithm. 

F.l DEFINITIONS 

In the following pages, the abbreviation DC means "Dynamic Configuration" and the abbreviation SC means 
"Static Configuration." 

• A DC device is a device whose Logical Address can be programmed via the VMEbus by a DC Resource 
Manager. 

• An SC device is any device whose Logical Address is fixed manually and cannot be changed, except 
through manually configuring fhe device. 

• A DC Resource Manager is a Resource Manager which supporfs Dynamic Configurafion. 

• A SC Resource Manager is any Resource Manager which does nof supporf Dynamic Configurafion, i.e., a 

Resource Manager as defined in Section C.4.1, "Resource Manager". 

• A DC sysfem is a VXIbus system wifh a DC Resource Manager. 

• A SC sysfem is a VXIbus system wifh a SC Resource Manager. 


F.2 DC DEVICE REQUIREMENTS 

DC devices have fhe standard VXIbus configurafion registers wifh some additional requiremenfs. Each DC 
device has a Logical Address Register, used for selling fhe device's Logical Address. In addition, fhe device has 
cerlain information encoded in ils Offsel register al power-on. DC devices are also required lo supporf fhe 
MODID line. 


F.2.1 Logical Address Register 

RULE F.2.1: 

Each DC device SHALL have a writable Logical Address register located al address offsel 0 (OOie) of ils 
configuration registers, conforming lo fhe following formal: 


Bit# 

15^8 

7^0 

Contents 

Undefined 

Logical Address 


The fields of fhe Logical Address register are defined as follows: 

• Undefined: The values written lo Ihese bils have no effecl. 

• Logical Address: The value written lo Ihis field is fhe device's new Logical Address. 
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RULE F.2.2: 

A DC device SHALL move its Logical Address before DTACK* is released during the write cycle which 
transfers the new Logical Address. 

RULE F.2.3: 

Any DC device which has moved to a new Logical Address SHALL NOT respond to any further accesses at its 
old Logical Address. 

OBSERVATION F.2.1: 

Like all VXIbus devices, DC devices must have non-volatile Logical Address selectors. 

PERMISSION F.2.1: 

A Static Configured VXIbus device MAY have a functional Logical Address register. 


F.2.2 DC Device Logical Address Assignment 

A fundamental requirement of Dynamic Configuration is that at power-up time, all DC devices are set to 
Logical Address 255 (FFjg). The Resource Manager will expect to find all DC devices at that Logical Address. 
Devices at all other addresses are assumed to be SC devices. 

RULE F.2.4: 

Upon the assertion of SYSRESET*, a DC device SHALL assume the Logical Address indicated by its Logical 
Address Selector. 

OBSERVATION F.2.2: 

Setting the Logical Address selector of a DC device to 255 (EEig) will cause a DC device to participate in the 
dynamic Logical Address assignment process. Setting the DC device Logical Address to any other Logical 
Address will fix the DC device at that Logical Address. 

RULE F.2.5: 

SC-only devices SHALL NOT be set at Logical Address 255 (EEig) in DC systems. 


F.2.3 Offset Register 

Multiple device modules may share address-decoding hardware. This can result in a significant hardware 
reduction. In such a case, the devices will share one or more Logical Address bits. A set of such devices is 
defined to be "address-blocked." These devices will be configured to a block of contiguous Logical Addresses. 
The Offset register is used to indicate the number of devices sharing the addressing hardware. 

RULE F.2.6: 

After SYSRESET* is unasserted and prior to entering the SELE TEST state, a DC device SHALL load its 
Offset register in the following format: 


Bit# 

15 ^8 

7^0 

Contents 

Undefined 

Devices 


The fields of the Offset register are defined as follows: 

• Undefined: The confenfs of fhis field are undefined and nof used. 

• Devices: The value in fhis field is fhe number of devices sharing fhe common address-decoding hardware. 
Values of 0, 1 and 255 all indicate a single device. 

The devices will have fhe teas! significanl bifs of fheir Logical Addresses hard wired fo predefermined values 
and will share fhe decoding hardware for fhe mosf significanl bifs. 
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RULE F.2.7: 

A set of address-blocked DC devices SHALL share address bits in accordance with the following table: 


Devices 

Shared Bits 

Hard-coded bits 

2 

7^1 

0 

3-4 

7^2 

1^0 

5-8 

7^3 

2^0 

9-16 

7^4 

3^0 

17-32 

7^5 

4^0 

33-64 

7^6 

5^0 

65 - 128 

7 

6^0 

129 -254 

- 

7^0 


RULE F.2.8: 

A set of address-blocked DC devices SHALL implement the lowest-valued block of contiguous Logical 
Addresses possible within its hard-coded bits. 

OBSERVATION F.2.3: 

The above rule guarantees that a set of address-blocked DC devices occupy the lowest-valued addresses 
available with its block of available addresses. 

OBSERVATION F.2.4: 

A write to the Logical Address register of an address-blocked module sets the values of all the related devices' 
Logical Addresses. 


F.2.4 MODID Support 

A DC device, when at Logical Address 255 (FFig), uses the MODID line as a device select qualifier. The 
device responds to data transfers when MODID is asserted. After the device has been moved to another 
address, the device responds at that address independent of the state of the MODID line. 

RULE F.2.9: 

A DC device SHALL use its MODID line as a device select qualifier for Logical Address 255 (FFig). 

RULE F.2.10: 

A DC device SHALL NOT use MODID as a device select qualifier for any Logical Address other than 255 
(FFie). 

OBSERVATION F.2.5: 

The effect of writes to a DC device's Logical Address register is independent of the state of the MODID line. 
Once the device has been assigned an address other than 255, writes to its Logical Address register will change 
its logical address, whether or not the MODID line is asserted. 

RULE F.2.11: 

DC modules which contain multiple DC entities which implement independent address decoding hardware 
SHALL respond to sequential accesses to Logical Address 255 (FFig), qualified with that module's MODID 
line, one entity at a time, until all entities have been moved to new Logical Addresses. 

OBSERVATION F.2.6: 

The entities referred to in the preceding rule may be single devices or a set of devices sharing address -decoding 
hardware. 
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RULE F.2.12: 

A multiple-board DC module must respond to exactly one MODID line, specified by the device designer. 


F.3 DC SYSTEM REQUIREMENTS 

The DC system Resource Manager must include the software necessary to implement the three-part 
configuration algorithm defined in the following section. Additionally, some limitations are imposed on 
Resource Manager and Slot 0 devices. 

RULE F.3.1: 

A DC system SHALL include a DC Resource Manager. 

RULE F.3.2: 

DC Resource Managers SHALL perform the system configuration responsibilities outlined in Section C.4.1, 
"Resource Manager", except for the Device Identification and Commander/Servant Hierarchy steps alternatively 
defined in fhe following paragraphs. 

OBSERVATION F.3.1: 

To meef fhe requiremenfs of Secfion C.4.1, fhe DC Resource Manager musf reside af Logical Address 0 (OOie). 
Therefore, fhe Resource Manager musf be a SC device and cannof be dynamically configured. 

A DC Resource Manager uses fhe Slof 0 confrolled MODID lines as board selecf qualifiers when assigning 
Logical Addresses. To access fhe Slof 0 devices, fhe Resource Manager musf know fhe Logical Addresses of 
fhe system Slof 0 devices. 

RULE F.3.3: 

Slof 0 devices SHALL be SC devices; i.e., Slof 0 devices cannof be dynamically configured. 

OBSERVATION F.3.2: 

SC devices may be included in a DC system. 

RULE F.3.4: 

Unless if is fhe Resource Manager, a VXIbus device SHALL NOT modify fhe logical address of any ofher 
VXIbus device by wrifing fo ifs Logical Address register. 


F.3.1 System Configuration Algorithm 

To configure a Dynamic Configurafion sysfem, fhe DC sysfem Resource Manager musf perform fhe following 
fhree major ftmcfions: 

• SC Device Idenfificafion 

• DC Device Logical Address Assignmenf 

The previous fwo funclions modify fhe "Device Idenfificafion" step of fhe inifializafion process ouflined in 
Secfion C.4.1, "Resource Manager". 

• Hierarchy Consfrucfion 

This funcfion modifies fhe "Assign Commander/Servanf Hierarchies" sfep of fhe inifializafion process ouflined 
in Secfion C.4.1, "Resource Manager". 
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F.3.1.1 SC DEVICE IDENTIFICATION 

In any Dynamic Configuration system, there will always be at least one and possibly several SC devices 
present: the DC Resource Manager and the system Slot-0 device(s). Also, users may wish to install other types 
of SC devices in DC systems. Since the Logical Addresses of these SC devices are fixed, the DC Resource 
Manager must first identify all SC devices as specified in Section C.4.1.1, "Device Identification". Having 
located the SC devices, the DC Resource Manager will not attempt to assign their Logical Addresses to any DC 
devices. 

OBSERVATION F.3.3: 

If an SC device is found at Logical Address 255 (FFig), no DC devices may be configured. 


F.3.I.2 DC DEVICE LOGICAL ADDRESS ASSIGNMENT 

After identifying the SC devices, the DC Resource Manager must assign Logical Addresses to all of the DC 
devices in the system. This requires that the DC Resource Manager: 

• Find every DC device by asserting each MODID line and reading a configuration register at Logical 
Address 255 (FFjg). 

AND 

• Write a new Logical Address to each DC device's Logical Address register. 

OBSERVATION F.3.4: 

No single order of asserting MODID lines is mandated. The order in which a DC Resource Manager asserts the 
MODID lines is at its manufacturer's discretion. Consequently, the order in which Logical Addresses are 
assigned to DC devices may vary from system to system. 

PERMISSION F.3.1: 

In assigning Logical Addresses, the DC Resource Manager may skip the access of slots which are known to 
contain SC devices. 

A DC resource manager may implement any procedure which assigns Logical Addresses to every DC device in 
the system, such as the following: 

For every Slot #1 - 12 in the system do the following steps (1 - 3): 

1. Assert the selected slot's MODID line. 

2. Repeat the following steps (a - c) until a bus error occurs. 

a. Read the Offset register at Logical Address 255 (FFig). 

b. If the Offset register indicates a single device, then determine the Logical Address to be 
assigned to that device. 

Otherwise, a set of address blocked devices is being accessed. Determine the Logical 
Addresses to be assigned to these devices (the lowest address of the block is written in the next 
step). 

c. Write the new Logical Address to the Logical Address register at Logical Address 255 (FFig). 

OBSERVATION F.3.5: 

An address blocked group of devices will modify only the shared bits of their Logical Addresses. The 
hard coded bits will cause the devices to occupy the lowest available Logical Addresses within the 
block defined by the shared bits. As a consequence, the first device will have Logical Address B*2*^, 
where B is the value assigned to the shared Logical Address bits and H is the number of hard-coded 
Logical Address bits. The last device will have Logical Address B*2^ -i- D - 1, where D is the number 
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of address blocked devices in the group. The Logical Addresses B*2^ + D through (B +1)*2^ -1 will 
be unused and available for assignment to other devices. 

RECOMMENDATION F.3.1: 

A DC resource manager should verify that each DC device is at its new Logical Address by reading a 
configuration register at the new Logical Address. 

3. De-assert the MODID line. 


F.3.1.3 HIERARCHY CONSTRUCTION 

DC Resource Managers are not required to respect the system hierarchy configuration encoded in the Servant 
are A-size of the system devices, as defined in Section C.4.L4, "Commander/Servant Hierarchies". 

RULE F.3.5: 

IF the DC Resource Manager does not respect the hierarchy encoded in the Servant are A-size of the 
system devices, 

THEN the DC Resource Manager SHALL provide some means for building an initial hierarchy. 
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APPENDIX I. VXIbus REGISTER OVERVIEWS 


This section is provided to improve the overview of the VXIbus configuration registers. The following figures 
conlain register maps for Ihe various device types and register conlenls overviews. 

Signalure explanalion: 

[ ]: Oplional register or field 

# : Register wilh localion monitor 

(): Required for parlicular type of device. 


REVISION: 4.0 


VXIbus Specification 


May 27, 2010 Printing 



Appendix I: VXIbus REGISTER OVERVIEWS 


Page 239 


DEVICE DEPENDENT 
REGISTERS 


BASIC 

CONFIGURATION 

REGISTERS 


3E 


3C 


3A 


38 


36 


34 


32 


30 


2E 


2C 


2A 


28 


26 


24 


22 


20 


IE 


1C 

Enhanced Capabilities Register 

1A 


18 


16 


14 


12 


10 


OE 


OC 


OA 


08 

(Slot 0 : MODID Register) 

06 

[Offset Register] 

04 

Status / Control Register 

02 

Device Type 

00 

ID Register 


16 bit words 


Figure I.l. Register Map for Register Based Devices 
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DEVICE DEPENDENT 
REGISTERS 


BASIC 

CONFIGURATION 

REGISTERS 


3E 


3C 


3A 


38 


36 


34 


32 


30 


2E 


2C 


2A 


28 


26 


24 


22 


20 


1E 


1C 

Enhanced Capabilities Register 

1A 


18 


16 


14 


12 


10 


OE 


OC 


OA 


08 

Attribute Register 

06 

[Offset Register] 

04 

Status / Control Register 

02 

Device Type 

00 

ID Register 


16 bit words 


Figure 1.2 Register Map for Memory Devices 
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3E 



3C 



3A 



38 



36 



34 


DEVICE 

32 


30 


DEPENDENT 

REGISTERS 

2E 



2C 



2A 



28 



26 



24 



22 



20 


VXIbus 

1E 


RESERVED 

1C 

Enhanced Capabilities Register 

REGISTERS 

1A 



18 


SHARED 

16 

[ A32 Pointer Low ] 

MEMORY 

14 

[ A32 Pointer High ] 

PROTOCOL 

12 

[ A24 Pointer Low ] 

REGISTERS 

10 

[ A24 Pointer High ] 


OE 

Data Low 

CONFIGURATION 

OC 

[ Data High ] 

REGISTERS 

OA 

Response [ / Data Extended ] 


08 

Protocol [ / Signal ] Register 

BASIC 

CONFIGURATION 

REGISTERS 

06 

[Offset Register] 

04 

Status / Control Register 

02 

Device Type 

00 

ID Register 


16 bit words 


Figure 1.3. Register Map for Message Based Devices 
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3E 

3C 

3A 

38 

36 

34 

DEVICE DEPENDENT 

REGISTERS 30 

2E 

2C 

2A 

28 

26 

24 


22 

20 

1E 

1C 

1A 

18 

DEVICE DEPENDENT 

REGISTERS 14 

12 

10 

OE 

OC 

OA 

08 


BASIC 

CONFIGURATION 

REGISTERS 


06 

04 

02 

00 


















Subclass Register 

Enhanced Capabilities Register 











[Offset Register] 

Status / Control Register 

Device Type 

ID Register 


16 bit words 


Figure 1.4. Register Map for Extended Devices 
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Figure 1.5. Register Overview for Basic Configuration Registers 
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Figure 1.6. Register Overview for MODID Register in Register Based Slot 0 Devices 
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Figure 1.7. Register Overview for Attribute Register in Memory Devices 
May 27,2010 Printing VXIbus Specification 
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Figure 1.8. Register Overview for Subclass Register in Extended Devices 
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Figure 1.9. Register Overview for Communication Registers 
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APPENDIX II. SUGGESTED BACKPLANE DESIGN 

II.1 BACKPLANE STRUCTURE (DEPRECATED) 

A reasonable backplane layer assignment that minimizes noise and maximizes high frequency performance 
follows: 


TOP (CONNECTOR SIDE) 

I 

GROUND PLANE 

2 

SIGNAL LAYER (TTL) 

3 

+5 VOLT PLANE 

4 

GROUND PLANE 

5 

-5.2 VOLT PLANE 

6 

-2 VOLT PLANE 

7 

SIGNAL LAYER (ECL) 

8 

GROUND PLANE 

BOTTOM (SOLDER SIDE) 


By making layers 1 and 8 ground planes, EMI is reduced because of the shielding of the internal traces. Layer 
1 also provides the ground layer for attachment of the EMI gasketing to the instrument modules. The thickness 
between planes 3 and 4, planes 4 and 5 and planes 6 and 7 should be as small as possible (0.005 inches is 
reasonable). This provides high distributed capacitance between those layers and allows high di/dt in the 
voltage planes. One signal layer also exists between the ground layer and the + 5 layer. Since -2 Volts is the 
signal return for ECL signals, layer 7 should contain as many of the critical ECL signals as possible. 


II.2 BACKPLANE LAYOUT (DEPRECATED) 

While noise in any logic system can be due to electrostatic coupling, the primary means of coupling is usually 
due to electromagnetic coupling. The key to designing a low noise system, where electromagnetic coupling is 
the primary noise source, is the control of current loop areas. Shields or guard stripes do not work. In fact, the 
main reason for a ground plane is not that is a shield, but that if signal current is adjacent to a neighboring 
plane, the width of the loop is the spacing between the signal current and that plane. This creates the smallest 
possible loop area. A designer should always examine the route that any return current may take. 
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Circuit number I 


+ 5 Volts 



0.001 //E Low 
Inductance 
Capacitor 


Circuit number 2 



In Eigure II.I, if Circuit number I is driven, then there must be a return current. This return current forms a 
loop, called loop area 1. Circuit number 2 is assumed to be quiet. However there is also a loop area in this 
circuit which consists of the signal current path and the return current path. The noise induced in the signal 
line of Circuit number 2 is directly proportional to the loop areas 1 and 2. If these two loop areas are large 
enough, it is possible to generate a voltage in Circuit number 2 large enough to create a threshold crossing. 

Please note that there is another "hidden" loop in Eigure ILL This is the power supply current path. When the 
receiving gate in Circuit number 1 changes state, a large amount of current is drawn from the supply voltage 
line. If a voltage plane is used, the loop area due to this current will be small. If a plane isn't used (or if the 
plane is discontinuous), then the loop area of the power supply return current can be quite large (it could 
encompass the entire board). If this area is not controlled, it can easily become the dominant noise source. In 
fact, when ground and voltage planes are not used, this power supply loop is almost always the dominant noise 
source. If power and ground planes are used, the need for external capacitors is reduced because of the high 
distributed capacitance. 

IT IS HIGHLY RECOMMENDED THAT GROUND AND VOLTAGE PLANES ALWAYS BE USED 
(PARTICULARLY ON THE BACKPLANE) AND A LOW INDUCTANCE, LOW ESR 0.001 ^mE 
CAPACITOR BE PLACED AS CLOSE AS POSSIBLE TO THE POWER AND GROUND PINS OE 
GATES. 
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Eigure II.2 shows a pair of gates that exist on a PC board with a ground plane, but with a cut made in the 
ground plane. 


Backplane 



Figure II.2. Loop Area with Cut in Ground Plane 


In Eigure II.2 the signal is routed on a layer other than the ground plane. If the "ground plane cut" had not 
been made the return current would exist adjacent to the signal run, but on the ground plane. With the "cut" 
the return current is forced away from the signal current, creating a large loop area. The layout shown in 
Eigure II.2 will typically create large amounts of noise. It will also typically receive large amounts of noise. 

FOR BEST RESULTS DON'T MAKE ANY CUTS IN A GROUND PLANE OR VOLTAGE PLANE 
EOR ANY REASON. 
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APPENDIX III. Support of Earlier VXIbus Revisions 

As the VXIbus specification has evolved, it has been necessary to tighten some of its requirements in order to 
minimize incompatibilities between devices. This appendix highlights the most important differences between 
this document and its earlier versions. In addilion, il offers recommendalions for maximizing compalibilily 
wilh earlier implemenlalions. 


III.1 REVISION 1.2 DEVICES 

Some word serial commands lhal were oplional in Revision 1.2 of Ihe VXIbus specificalion are now required. 
Revision 1.2 also permitted some aclivilies lhal are now prohibited. The following is a minimal sel of 
exceplions lo Ihe presenl specificalion which, if implemented by Ihe Commander or Resource Manager, should 
provide compalible support of a Revision 1.2 servanl-only device. A bil in Ihe response lo Ihe Read Protocol 
command idenlifies Revision 1.2 devices. 

RECOMMENDATION III.1.1: 

A Resource Manager should implemenl Ihe following operalional changes when communicaling wilh a 
Revision 1.2 Message Based device. 

• Identify any Message Based device lhal responds lo Ihe Read Protocol command wilh bil 15 cleared lo (0) 
as a Revision 1.2 device. 

• Identify any Revision 1.2 devices lhal do nol supporl Ihe Err* bil. This is indicated by a 1 in bil 7 of Ihe 
response lo Ihe Read Protocol command. 

• If Ihe device does nol supporl Ihe Err* bil, Ihe device will reporl unsupported commands wilh Ihe 
"unrecognized command" evenl which was defined for Revision 1.2 Message Based devices. This evenl 
will be relumed as an evenl signal if Ihe device is a VMEbus Master or as an evenl inlermpl if Ihe device 
is nol a Master. The Resource Manager should provide an evenl handler for Ihese "unrecognized 
command" evenls and utilize Ihe unsupported command information as necessary. 

• A Revision 1.2 device will nol relum a response lo Ihe Begin Normal Operation command. Therefore a 
Resource Manager or Commander should nol expecl one. 

• Revision 1.2 did nol prohibil inlermpl generation by a device when nol in Ihe NORMAL OPERATION 
sub-slale. The Resource Manager should nol send Ihe Read STB, Read Protocol Error, End Normal 
Operation or Abort Normal Operation commands (all optional in Revision 1.2) lo a device prior lo a Begin 
Normal Operation command lo avoid unwanted inlerrapls prior lo Ihe NORMAL OPERATION sub-slale. 

• The End Normal Operation and Abort Normal Operation commands were optional commands for servanl- 
only devices in Revision 1.2. Resource Managers or Commanders should eilher nol send Ihese commands 
lo Revision 1.2 devices or provide for handling of a possible "unrecognized command" evenl inlermpl or 
signal. Since Ihese termination commands may nol be supported by Ihe device, proper termination of Ihe 
device may be application specific. 

• The Asynchronous Mode Control, Control Response, Control Event, Abort Normal Operation, End 
Normal Operation and Read STB commands, if supported by a Revision 1.2 device did nol require bils 15- 
8 of Ihe "successfully completed" response lo Ihese commands lo be sel lo one. The Resource Manager or 
Commander should mask bils 15-8 when interpreting Ihe response from Ihese commands. The Control 
Event command did nol specify a response in Revision 1.2. Therefore, Ihe Resource Manager or 
Commander should nol expecl one. The EG* and RG* fields of Ihe Read Protocol command were nol 
defined in Revision 1.2. Lack of supporl for Ihe Asynchronous Mode Control, Control Response, Control 
Event, Abort Normal Operation, End Normal Operation and Read STB commands is indicated by an 
unsupported command error. 
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• If Programmable Handler (PH) or Programmable Interrupter (PI) capability is supported by a Revision 1.2 
device, the responses to these commands differed from the present specification. The Assign Handler Line 
and Assign Interrupter Line commands did not permit a response and the Read Handlers, Read Handler 
Line, Read Interrupters and Read Interrupter Line commands did not require bits 15-3 of the response to 
be set to one. The Resource Manager or Commander should not expect a response to the Assign Handler 
Line or the Assign Interrupter Line commands and should mask bits 15-3 when interpreting the response to 
the Read Handlers, Read Handler Line, Read Interrupters and Read Interrupter Line commands. 

• DOR and DIR support was not required by Revision 1.2 devices. Devices which did not support DIR and 
DOR held the associated bits high. A Resource Manager or Commander may not assume that the DOR 
and DIR bits in a Revision 1.2 device will accurately reflect the device's state. 


III.2 REVISION 1.3 DEVICES 

The Word Serial protocol error handling requirements and Past Handshake protocol requirements for servants 
have been tightened in Revision 1.4. 

Revision 1.3 devices were allowed to queue protocol errors. Queuing is no longer allowed. A device must 
now un-assert (to 1) its Err* bit after receiving the Read protocol error command, before it re-asserts its Write 
Ready bit. A Revision 1.3 device was allowed to maintain its Err* indication until it asserts its Read Ready bit 
when writing its last (queued) error code to its Data Low register. This made it difficult for a commander to 
distinguish between a Read protocol error command resulting in an error, a slow response to the command and 
a normal response (with more error codes queued). To maintain the best compatibility with such devices, a 
commander should not test a servant's Err* bit after a Read protocol error command until the servant has 
asserted its Read Ready and Write Ready bits or a very long time has elapsed. 

A permission in Revision 1.3 allowed servants in the Past Handshake mode to continuously assert both their 
Read Ready and Write Ready bits. Some Revision 1.3 devices may thus assert their Read Ready bits at times 
when their commanders have not initiated any queries. A commander that implements rigorous error checking 
might test this bit before sending a word serial query and interpret it as an error condition. In order to avoid 
this problem, a commander should ignore any Read Ready indications from a Past Handshake servant prior to 
sending word serial queries. 


III.3 REVISION 2.0 DEVICES 

A64 capability has been added in Revision 3.0. A new register, the Enhanced Capabilities register, has been 
added so that devices can report themselves as A16/A64 devices. Resource Managers designed to Revision 2.0 
and earlier will not recognize this new register and will be unable to configure the A64 address space. 

Note that a Resource Manager that does not perform A64 bus master accesses and does not respond to A64 
accesses still needs to be able to configure A64 space. In a system where devices other than the Resource 
Manager are capable of performing or responding to A64 accesses, a Resource Manager designed to Revision 
2.0 of the specification will prevent the A64 devices in the system from accessing each others A64 operational 
registers. A system integrator or end user using A64 devices must ensure that the Resource Manager is capable 
of A64 address space allocation, as described in section C.4.1.3 of this specification. 
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III.4 REVISION 3.0 DEVICES 


Modules designed for VXI-1 Rev 3.0 and older will work in VXI-1 Rev. 4.0 mainframes 
Modules designed according to VXI-1 Rev. 4.0 that do not use any of the signals/supply 
voltages located on rows “z” and “d” of P1/P2 or can work with reduced functionality 
without access to rows “z” and “d” (e.g. Star Trigger lines not available for triggering), 
will work in pre-4.0 mainframes. 

Modules requiring signals/supply voltages located on rows “z” and “d” (e.g. 3.3V) 
require a mainframe designed according to VXI-1 Rev. 4.0 

Modules that have shielding that connect to 96-pin connectors will not fit into new 160- 
pin J1 or J2 connectors. Shielding will have to be removed, or the VXIbus 4.0 compliant 
backplane will have to supply 96-pin connectors for backwards compatibility. 
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CONFIGURATION REGISTERS: A device's A16 registers which are required for the system configuration 
process. 

BACKPLANE: An assembly, typically a PCB, with 96-pin connectors and signal paths that bus the connector 
pins. VXIbus systems will have two sets of bussed connectors, called the J1 and J2 backplanes or have three 
sets of bussed connectors, called the Jl, J2 and J3 backplane. 

BOARD: A blank PCB. 

BOARD ASSEMBLY: A board and its associated electrical components and connectors. 

CHASSIS SHIELD: A shield that resides between two modules and attaches to the mainframe. 

COMMAND: Any communication from a commander to a message based servant, consisting of a write to the 
servant's Data Low register, possibly preceded by a write to the Data High or Data High and Data Extended 
registers. 

COMMANDER: A message based device which is also a bus master and can control one or more servants. 

DEVICE: A component of a VXIbus system. Normally, a device will consist of one VXIbus board. 
However, multiple-slot devices and multiple-device module are permitted. Some examples of devices are 
computers, multimeters, multiplexers, oscillators, operator interfaces and counters. 

DEADLOCK: A condition in which two devices are each trying to acquire a resource held by the other 
device. No progress can be made until one of the devices relinquishes its resource. 

DYNAMIC CONEIGURATION: A method of automatically assigning Logical Addresses to VXIbus devices 
at system power-on or other configuration times. It allows for each slot to contain one or more devices as well 
as different devices within a slot to share address decoding hardware. 

EVENTS: Signals or interrupts generated by a device to notify another device of an asynchronous event. The 
contents of events are device dependent. 

EAST HANDSHAKE: A high speed mode of operation which uses the same communication registers as the 
word serial protocol and allows data transfer without the need for polling after each transfer. 

EXTENDED DEVICES: A device that has VXIbus configuration registers and a subclass register. This 
category is intended to allow for definition of additional device types. 

EXTENDED LONGWORD SERIAL: A form of WORD SERIAL communication that allows 48-bit data 
transfers between commanders and servants. 

HYBRID DEVICE: A VMEbus compatible device that includes application specific subsets of VXIbus 
protocols. 

LIVELOCK: A condition of recurring deadlock. Livelock occurs when devices repetitively acquire some 
resources, experience a deadlock, relinquish some resources, acquire the same resources and experience a 
similar deadlock. 

LOCATION MONITOR: A function that monitors data transfers over the VMEbus in order to detect 
accesses to the locations it has been assigned to watch. When an access occurs to one of these assigned 
locations, the LOCATION MONITOR generates a local signal. 

LOGICAL ADDRESS: An 8-bit number which uniquely identifies each VXIbus Device in a system. If 
defines a device's AI6 register addresses and indicates Commander/Servanf relafionships. 

LONGWORD SERIAL: A form of WORD SERIAL communicafion fhaf allows 32-bil dafa Iransfers 
befween commanders and servanfs. 
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MAINFRAME: A rigid framework that provides mechanical support for modules inserted into the backplane, 
ensuring that connectors mate properly and that adjacent modules do not contact each other. It also provides 
cooling airflow and ensures that modules do not disengage from the backplane due to vibration or shock. 

MEMORY DEVICE: A device which contains only memory and implements configuration registers. 

MESSAGE BASED DEVICE: An intelligent device which implements the defined VXIbus registers and 
communication protocols. 

MODULE: Typically consists of a board assembly and its associated mechanical parts, front panel, optional 
shields, etc. A module contains everything required to occupy a slot in a mainframe. A module may occupy 
one or more slots. 

OBSERVATION: Observations spell out implications of rules and bring attention to things that might 
otherwise be overlooked. They also give the rationale behind certain rales, so that the reader understands why 
the rale must be followed. 

OPERATIONAL REGISTER: An operational register is any register on a device that is not required for the 
system configuration process. 

PERMISSION: Permissions are included to clarify the areas of the specification that are not specifically 
prohibited. Permissions reassure the reader that a certain approach is acceptable and will cause no problems. 
The word MAY is reserved for indicating permissions. 

RECOMMENDATION: Recommendations consist of advice to implementers which will affect the usability 
of the final device. Discussions of particular hardware to enhance throughput would fall under a 
recommendation. These should be followed to avoid problems and to obtain optimum performance. 

REGISTER BASED DEVICE: A servant only device which supports VXIbus configuration registers. 
Register based devices are typically controlled by message based devices via device-dependent register reads 
and writes. 

RESOURCE MANAGER: A message based commander located at Logical Address 0 which provides 
configuration management services such as address map configuration, commander/servant mappings, self test 
and diagnostics management. 

RESPONSES: Signals or interrupts generated by a device to notify another device of an asynchronous event. 
Responses contain the information in the sender's Response register. 

RETRY: To attempt a data transfer again, because the prior data transfer attempt did not return valid data. 
This is not to be confused with the VME64 RETRY* signal, which a slave device uses to inform the bus 
master that a data transfer cannot be completed and should be retried. 

RULE: Rules SHALL be followed to ensure compatibility for cards in the system. A rale is characterized by 
the use of the words SHALL and SHALL NOT. These words are not used for any other purpose other than 
stating rales. 

SERVANT: A device that is controlled by a commander. There are message based and register based 
servants. 

SERVANT POINTER: An 8-bit number which is the Logical Address of the lowest numbered servant 
associated with this commander. 

SHARED MEMORY PROTOCOL: A communication protocol designed to allow message based devices to 
communicate by sharing an area of memory accessible to both. The protocol specifies connection and 
operation sequences to be followed by both devices. 

SIGNAL: Any communication between message based devices consisting of a write to a Signal register. 
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SLOT: A slot is a position where a module can be inserted into a VXIbus backplane. Each slot provides the 
96-pin J connectors to interface with the board P connectors. It may have to provide one, two or three 
connectors. 

SUGGESTION: A suggestion contains advice which is helpful but not vital. The reader is encouraged to 
consider the advice before discarding it. Suggestions are included to help the novice designer with areas of 
design that can be problematic. 

SYSTEM: A system consists of one or more mainframes that are connected, all sharing a common resource 
manager. Each device in a system has a unique Logical Address. 

VXIbus INSTRUMENT: A VXIbus INSTRUMENT is defined to be a MESSAGE BASED DEVICE which 
supports the VXIbus Instrument protocols. 

VXIbus SUBSYSTEM: A VXIbus Subsystem consists of a central timing module referred to as Slot 0 with up 
to twelve additional adjacent VXIbus modules. The VXIbus Subsystem bus defines the lines on the P2 and P3 
connectors. 

WORD SERIAL: The simplest required communication protocol supported by Message Based devices in the 
VXIbus system. It utilizes the A16 communication registers to transfer data using a simple polling handshake 
method. 

488-VXIbus INTEREACE DEVICE: A 488-VXIbus INTERLACE device is a MESSAGE BASED DEVICE 
which provides communication between an IEEE 488 Interface and the VXIbus Instruments. 
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A16 address space, 8, 104, 106, 107, 130 

A16 configuration registers, 128, 166 

A16 only device, 108, 109, 111 

A16/A32 device, 111, 167 

A24 Pointer Register, 138 

A24 VMEbus, 109 

A24/A32/A64 Active, 109, 120 

A32 Address Map configuration, 167 

A32 Non-VXIbus, 130 

A32 Pointer register, 134 

A32 Pointer Register, 138 

A32 Register Based, 130 

A32 VMEbus, 109 

Abort Normal Operation, 139, 140, 142, 143, 144, 146, 
147, 149, 150, 151, 163, 168, 170, 187, 188, 197, 229 
Acceptor Handshake, 180 
ACFAIL, 12 

address blocked devices, 213, 214 
Address Map Configuration, 103, 167 
address modifiers, 4, 9,112 
address-decoding hardware, 210, 211 
Addressing Talker, 180 
analog summing node, 37 
arbiter, 12, 30, 46 
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A-size, 59 

Assign Handler Line, 132, 140, 142, 145, 169, 188, 189, 
201, 230 

Assign Interrupter Line, 131, 143, 145, 169, 188, 190, 201, 
230 

ASYNC, 26, 27, 28, 31, 34, 35 
Attribute Register, 128, 222 

B 

backplane connectors, 53, 56, 60, 98, 100 

backplane ECL lines, 50 

backplane layout, 225 

backplane structure, 225 

base address, 104, 106, 111, 126, 133, 167, 171 

base address offsets, 167 

BERR, 4, 10, 11, 135, 136, 157, 158, 159, 161, 162, 163 

block transfer capability, 128 

block transfer cycle, 123 

board assembly, 54, 69, 70, 233 

board select qualifiers, 212 

board warpage lead length, 54 

B-size, 59 

BTO, 11 


buffer, 20, 31, 37, 46, 47, 174 
bus grant, 12 

Bus Request/Grant, 12, 122, 123 
Bus Requesters, 122 
Bus Timer Operation, 11 

Byte Available, 137, 140, 157, 160, 161, 162, 173, 174, 
176, 177, 181, 187, 193 
byte blocks, 104 

Byte Request, 137, 140, 157, 160, 161, 162, 173, 174, 183, 
187, 193 
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center row, 3, 15 
central handling, 15 
chassis ground, 55, 57, 60, 61, 62, 94 
chassis shield, 5, 57, 61 

Clear command, 147, 151, 163, 174, 175, 177, 183, 193 
Clear Lock, 140, 173, 175, 176, 184, 187, 193 
CLK10, 4, 12, 20, 30, 36, 43, 170, 172 
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clock signal transmission, 28, 35 
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CMDR, 134, 142, 167 
COMMANDER, 167, 232 
Commander Servant communication, 154 
Commander/Servant hierarchy, 103, 145, 168 
Commander/Servant mapping, 168 
common system resources, 165 
communication ability, 102 
communication element, 154 
communication protocois, 4,102,103,104,130,139, 
143, 233 

communication registers, 102, 133, 134, 136, 232, 234 
component height, 4 
component lead length, 54 
computer systems, 3 
conducted emissions, 94, 105 
conducted susceptibility, 94, 106 
Configuration Registers, 2, 102, 107, 126, 129, 133, 152, 
171, 172, 220 

Control Register, 107, 110, 119 
cooling air, 57, 62 

c-size, 4, 5, 59, 69, 72, 74, 76, 79, 81, 85 
Current Error State, 163 
current flow, 90, 105 

D 

D16 STATUS/ID, 121, 132 
D16 STATUS/ID Transfer, 121 
D32 Extension, 121, 125, 132 
D32 STATUS/ID, 121 
D32 STATUS/ID Transfer, 121 
daisy chained bus, 39 
daisy-chain lines, 12 
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data bytes, 180 

Data Extended, 134, 138, 151, 156, 157, 232 
Data High, 134, 137, 138, 151, 156, 157, 232 
Data In Ready, 137 

Data Low register, 137, 138, 146, 149, 150, 156, 158, 161, 
162, 188, 189, 190, 191, 192, 193, 194, 195, 197, 198, 
199, 200, 201, 202, 203, 204, 205, 230, 232 
Data Out Ready, 136 
data register, 155 

data registers, 134, 137, 138, 155, 156, 174 

data transfer bus, 9, 12 

data transfer capabilities, 125, 130 

data transfer cycle, 137, 158 

data transfer, commander, 174 

data transfer, instruments, 174 

data transmission, 29, 35 

DC device, 209, 210, 211, 213, 214 

DC device requirements, 209 

DC Resource Manager, 209, 212, 213, 214 

DC system requirements, 212 

DC system Resource Manager, 212 

DC voltage specifications, 90 

Deassertion of SYSRESET, 166 

design rules, 173 

determine, 13, 154, 167, 174, 198, 199, 200, 213 

determining, 103, 108 

device addressing, 104 

device capabilities, 154 

Device Clear, 174, 177, 180 

Device Clear Requirements, 174, 177 

device communication protocols, 154 

device dependent operational registers, 126 

Device Dependent Registers, 112 

device identification, 166 

device initialization, 4 

device operation, 102, 117, 129 

device slave capabilities, 104 

Device Trigger, 180 

Device Type register, 109, 111, 114, 124, 167, 171, 172 
DIR, 136, 137, 144, 158, 159, 160, 161, 162, 163, 174, 175, 
177, 181, 184, 187, 195, 196, 202, 230 
DOR, 136, 137, 144, 158, 159, 160, 161, 162, 163, 174, 

177, 183, 187, 195, 202, 230 
driving rules, 24, 31, 37 
DSO, 107, 108, 129 
DSl, 107, 108, 129 

D-Size, 4, 5, 47, 59, 64, 70, 73, 75, 77, 80, 82, 86 
D-size Slot 0, 47 
DTB, 123 

dynamic configuration, 4,13,108, 111, 120,127,165, 
170, 209, 210, 212, 213 
dynamic current, 91, 93, 94, 105 
Dynamic Module Current, 93, 94 

E 

ECL signal levels, 50 

ECLTRG, 4, 32, 33, 34, 35, 36, 37, 38, 46, 50 

ECLTRG ASYNC, 34 

ECLTRG ESTST 36 

ECLTRG SYNC, 33, 34, 35 

ECLTRG trigger protocols, 46 


ECLTRGO-1 lines, 48 

electrical specifications, 14 

electromagnetic compatibility EMC, 3, 5, 54, 98 

electromagnetic coupling, 225 

electrostatic coupling, 225 

electrostatic discharge, 94 

EMC, 4, 3, 13, 54, 56, 57, 90, 94, 98, 101, 102, 103, 104 
emissions, 94, 96, 97, 98, 100, 105, 106 
End Normal Operation, 139, 141, 142, 143, 146, 147, 149, 
150, 151, 163, 170, 187, 197, 229 
EOI, 181, 183 
ERR, 161 

error, 4, 114, 136, 137, 155, 159, 161, 162, 163, 164, 166, 
176, 177, 179, 192, 197, 202, 203, 205, 213, 229, 230 
error condition, 230 
error reporting, 176 
error state, 163, 202 
ESTST protocol, 36, 37, 46 
Extended Device register map, 152 
extended devices, 4,104,152, 219, 223 
extended longword, 137, 155, 156, 157, 201, 207 
extended longword serial, 137, 155, 157, 201, 207 
extended longword serial commands, 207 
extended longword serial protocol, 201 
extended longword serial transfer, 157 
extended registers, 151 
extended START/STOP, 36 
external events, 30, 46 
external instruments, 27, 31, 34 
external interface, 181, 183 
external trigger buffering, 31, 37 
external wiring, 56 

F 

Railed LED, 113, 114, 119 
fair requester protocol, 122 
Fast Handshake Transfers, 4,134,137 
EHS, 134, 136, 137, 144, 148, 157, 158, 159, 161, 162, 
195, 196 

filler panels, 55, 56 
front panel area, 56 
front panel dimensions, 55 
front panel handles, 56 
front panel interface, 56 
front panel mounting, 55 
front panels, 55, 61 
front view, 52 

functional memory locations, 129 

G 

generalized model, 155 

grant device command, 144, 198 

ground pins, 226 

ground plane, 225, 227 

grounding, 61, 98 

Group Execute Trigger, 46, 180 

guaranteed setup, 46 
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Handler Line, 132, 141, 142, 169, 188, 189, 198, 201, 230 

handling, 4, 54, 57, 229, 230 

hard reset, 114, 116, 120, 123, 126, 143, 147, 148 

hierarchical instrumentation system, 154 

hierarchical levels, 168 

hierarchy construction, 212, 214 

High Current 3 State, 24 

higher level communication protocols, 102 

hold times, 26, 29, 30, 46 

host computer, 101, 102, 103, 169 

humidity, 58, 63 

hybrid devices, 104 

I 

lAC, 9 

ID, 4, 2, 13, 106, 107, 108, 111, 114, 119, 120, 121, 122, 
124, 125, 126, 129, 132, 133, 136, 152, 153, 167, 189, 
190, 198, 199, 208 
ID Register, 106, 107 
lEC, 1, 52, 58, 63 
lEC publications, 52 

IEEE 488, 6, 173, 174, 175, 176, 177, 178, 179, 180, 181, 
183, 184, 185, 234 
IEEE 488 address, 179 
IEEE 488 address mapping, 179 
IEEE 488 device clear message, 183 
IEEE 488 interface, 183, 184 
IEEE 488 remote local, 184 
IEEE 488 serial poll function, 185 
IEEE 488 trigger message, 183 
IEEE 488 VXIbus interface, 185 
induced ripple/noise, 91, 92, 94, 105 
injection/ejection, 4 
instrument protocols, 4,173,177,187 
instruments, commanders, 174 
interfacing requirements, 173 
interference, 56, 59, 96, 98, 100 
intermodule communication, 26 
intermodule timing resource, 32 
internal state machine, 113 
internal traces, 225 

Interrupt Handler capability, 122, 131, 132, 145 
interrupt line, 131, 132, 133, 145 
Interrupt Request line, 120, 122 
interrupter capability, 120, 131, 132, 134, 142, 143, 144, 
145 

L 

LEVS, 39, 46 

level n requester, 122 

Load Ripple/Noise, 90, 91, 92, 94 

local bus, 6, 15, 39, 40, 43, 55, 56, 58, 62 

local bus incompatibilities, 58 

local bus lockout keys, 55, 56, 62 

location monitor, 135, 138 

locking devices, 184 

logical address, 168, 169, 211, 212 

Logical Address 0, 144, 165, 212, 233 

Logical Address Register, 107, 209 


logical addresses, 13, 165 
longword serial commands, 206 
longword serial protocol, 201 
longword serial transfer, 156 

M 

mainframe cooling, 62 
Mainframe Dynamic Current, 91, 92, 93 
mainframe output power, 93 
mainframe power supply, 12, 90 
mainframe shielding, 61 
mainframe specifications, 59 
manufacturer defined subclasses, 152 
manufacturer ID numbers, 108 

master capability, 122, 123, 125, 130, 134, 142, 144, 176 
mechanical specifications, 39 
memory configuration, 102 
memory device, 4,104,128,129 
memory device attribute register, 128 
memory device registers, 128 
Message Based Commander, 130, 142, 154, 165, 179 
message based device communication registers, 132, 133 
message based device registers, 133 
message based servant control, 154 
message based servants, 146, 150, 154, 169, 192, 197 
message based Slot 0 device, 171, 172 
messages, 130, 176, 177, 179, 180, 183, 184 
MODID line, 13, 14, 24, 25, 109, 171, 209, 211, 212, 213, 
214 

MODID register, 171, 204, 205 

MODID support, 170 

MODIDOO, 24, 25, 26, 171 

MODIDOO-12, 171 

module cooling, 57 

module current, 93, 94 

module environmental, 58 

module extraction, 61 

module front panels, 55, 61 

module identification pins, 15 

module input, 93 

module keying, 58 

module power, 58 

module shielding, 57 

module specifications, 52 

module supply pin, 106 

module width, 5, 54 

multiple device modules, 210 

multiple devices, 46 

multiple Interrupt Handlers, 132 

multiple Interrupters, 131, 190, 198, 199 

N 

NDAC, 183, 184 
No Cause/Status Given, 122 
no data, 136, 159 
No Extension Given, 121 
No Listen Only Mode, 180 
No Request, 122 

noise, 50, 90, 91, 92, 94, 105, 106, 225, 226, 227 
Non-Privileged, 112, 128 
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Non-VXIbus, 104, 122, 130 
Non-VXIbus devices, 104, 130 
normal operation, 93, 94, 117, 119, 139, 140, 141, 142, 
143, 144, 145, 146, 149, 150, 151, 169, 170, 188, 192, 
193, 197, 229 

normal transfer mode, 134, 157, 158, 159 

o 

offset register, 8 

open system architecture, 3 

operational registers, 108, 111, 126, 128, 129, 133, 230 
optional commands, 187, 229 

other device, 15, 105, 102, 126, 146, 147, 154, 168, 169, 
214, 232 

other functions, 172 
other Slot 0 devices, 172 
output buffer, 174 
Output Enable, 171, 200 

P 

PI, 3, 4, 5, 14, 53, 54, 58, 59, 102, 109, 184 

PI connector, 3, 14, 53 

P2 connector definition, 6 

P2 DIN SUMBUS, 39 

P2 MODID, 109 

P3 connector, 5, 6, 43 

P3 Connector, 6, 43 

P3 connector adds, 6 

PARD, 91, 105 

passed, 12, 115, 117, 166 

PC board, 54, 227 

PCB, 232 

peak, 91, 93, 94, 105, 107 

peak current, 91, 93 

Periodic And Random Deviations, 91 

Pointer register, 134, 138 

power compatibility, 93 

power distribution, 50, 91 

power distribution network, 50, 91 

power interrupt, 12 

power management, 4 

power monitor, 4,12 

power pins, 6, 90, 105 

power supply, 12, 58, 62, 91, 93, 94, 105, 106, 226 

power supply load, 105 

power-up time, 210 

Protocol Events, 133, 194 

Protocol register, 133, 136, 142, 146 

R 

radiated emissions, 96, 98, 100 

radiated susceptibility, 98 

rated current, 90, 105 

read data registers, 155 

Read Handler Line, 132, 169, 198, 230 

Read Handlers, 132, 141, 142, 188, 199, 201, 230 

Read Interrupters, 131, 141, 142, 169, 188, 200, 201, 230 

Read MODID, 141, 172, 187, 200 

read only register, 128 


Read Ready, 137, 140, 148, 151, 155, 156, 157, 158, 159, 
161, 162, 163, 177, 195, 196, 202, 230 
Read STB command, 176, 178, 185, 203 
ready bits, 113, 114, 158, 163, 230 
REC, 106, 131, 139 

register based device, 102, 125, 126, 127, 154, 171 
regulation, 125 

release device, 140, 142, 145, 187, 204 
Release On Acknowledge, 120, 131 
Remote/Local, 180 
request false, 176, 178, 184, 185 
request true, 176, 177, 178, 184, 185 
reserved registersREGISTERS, 134 
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